HN user

winton

162 karma
Posts2
Comments30
View on HN

For a project set up by a qualified engineer, there would be little difference to the end user in practice. The LLM would work out a solution with a negligible difference in speed. Maybe debugging would also be faster for the LLM without the abstraction layers and low level access?

In My Culture 7 years ago

It seems from the comments that this article rubs people the wrong way. This article might be getting grouped into a speech police category that is undeserved.

I think the intention of "in my culture" is to allay a fear in the listener. The speaker is worried that there is a strong expectation of change in the listener by stating something as an axiom. The speaker's hope is that the listener will see a possibility instead of a demand.

Some people think it should be obvious that what a person states should never be seen as a demand to conform. Some believe this is a necessary life skill, especially in business.

Some people are interested in finding ways of speaking in a more sensitive way in an era that seems to be embracing sensitivity.

Its interesting to me that both sides can see each other's ways of communicating as an affront, when it is likely not the intent on either side.

After using Redux for a while, I realized that I was creating a lot of boilerplate to essentially (1) update an immutable store and (2) pass that store's state to (a)sync callbacks that execute in serial before and after the store was updated.

This lead me to the creation of DotStore (https://github.com/invrs/dot-store#readme), along with extensions to use it with React [1] and the filesystem [2].

"Dot prop" strings have proved to be an elegant solution to detect which props changed on the store. Usually this means doing a regex match in `shouldComponentUpdate`. We almost never use React's state anymore.

[1] https://github.com/invrs/dot-store/tree/master/packages/dot-...

[2] https://github.com/invrs/dot-store/tree/master/packages/dot-...

Bleacher Report, San Francisco - http://bleacherreport.com

We are a sports media site that is revolutionizing journalism. We are the 2nd largest sports site (right behind ESPN) and a top 30 web site, reaching 80 million unique users per month. We love technology, we love to learn, and we love to have fun.

We are primarily a Ruby shop, but as we implement a service oriented architecture, we use increasingly diverse technologies. These technologies include Rails, Node.js, Redis, PostgreSQL, Backbone, Marionette, Docker, DynamoDB, Elastic MapReduce, Redshift, and more.

See our listings at http://eng.bleacherreport.com/jobs

Bleacher Report - San Francisco, CA (Financial District). Full time.

We are the 3rd largest sports news site in the United States, just behind ESPN, Fox Sports, and Yahoo.

Work on a site that reaches 70 million people per month while getting exposure to a variety of technologies (we routinely play with Ruby, Node.js, Elixir, and Go). We encourage our employees to contribute to open source as apart of their work at Bleacher Report, and most importantly, always be learning.

Email wwelsh@bleacherreport.com or visit http://bleacherreport.com/careers/engineering

Bleacher Report - San Francisco, CA (Financial District). Full time.

We are the 4th largest sports web site in the United States, just behind ESPN, Fox Sports, and Yahoo.

Work on a site that reaches 20 million people per month while getting exposure to a variety of technologies (we routinely play with Rails, Node.js, Redis, eventmachine, and Sinatra). We encourage our employees to contribute to open source as apart of their work at Bleacher Report.

http://bleacherreport.com/careers/engineering

Created my frame, left the site, came back, and placed an order.

Did not realize framous had not saved my picture orientation properly. Emailed to cancel order so I could place a new one. No response.

Now I will not be placing a new order at all.

Bleacher Report - San Francisco, CA (Financial District). Full time.

We are the 4th largest sports web site in the United States, just behind ESPN, Fox Sports, and Yahoo.

Work on a site that reaches 20 million people per month while getting exposure to a variety of technologies (we routinely play with Rails, Node.js, Redis, eventmachine, and Sinatra). We encourage our employees to contribute to open source as apart of their work at Bleacher Report.

http://bleacherreport.com/careers/engineering

Bleacher Report - San Francisco, CA (Financial District). Full time.

We are the 4th largest sports web site in the United States, just behind ESPN, Fox Sports, and Yahoo.

If you are a Rubyist who is looking to play with a wide variety of technologies, make big decisions on a relatively small team, and work on a site that reaches 20 million people per month, this is your place.

http://bleacherreport.com/careers/engineering

You are right. I would appreciate a fork to fix this very minor issue, but if not I will be getting to it very soon.

It can do everything nanoc does, but the execution is much simpler and much more natural. This is not just my opinion, but what I have heard from lots of people.

My apologies for the self-promotion, just trying to get the word out.

You can do all of this via controllers. You can execute any Ruby code you want before each template renders.

There is distinction between filters for content and layouts, simply use the layout filename in a before block.

You can execute any Ruby you want. You can use ActiveRecord, Redis, whatever. Load YAML for metadata. None of this stuff needs to be baked in, Ruby already does it.

[dead] 15 years ago

It makes me happy. Hopefully Mozilla is the first of many.

My first impulse is to say "backup but replace the a with a v". If you tell someone bee-vee-cup they still don't know how to spell the domain name.