techiferous

We follow a similar process where I work and it works really well.

Something being merged into development means that it is 100% complete and ready to be deployed to production at any time. This means all QA and acceptance testing had to happen before merging.

> The aspect of Ruby that frustrates me the most is over-use of anonymous blocks when a good name would help me enormously.

Ruby gives you enough tools to write code clearly with good names if you want to. I think your complaint might be more about the particular style of Ruby a certain programmer wrote than the language itself.

This design does not account for non-weekly parking rules, like "No parking during street cleaning on the third Tuesday of the month."

The motivation of the law is to raise revenue for transportation, not close a legal loophole.

Cambridge is a wonderful place to live: extremely walkable, pretty architecture, good food, plenty to do, tolerant social atmosphere, very tech-friendly. Not sure if it's fair to call Cambridge/Boston a "terrible" place to live.

I would say that the weather and recreation opportunities aren't as good as in some other locations of the country, so you have a point there.

Good Rails devs are hard to find and in large demand. As a beginning Rails developer, though, you'll need to convince your new employer that you are a net gain. A junior dev can need so much hand-holding that they can steal away precious time from a senior dev.

Put some good Ruby code on github. If you can, you'll improve your chances of getting hired quite a bit. If you can't then you're not ready to be hired yet.

This actually sets up a single point of failure for many apps. If a hacker were to hack rails.org, they could take down any site polling it.

Being a dvorak user, I must say, the "rolls" are extremely comfortable and fun.

I love typing the words church, tenth, school, etc.

"Dvorak, with a larger support failed."

If by failed you mean widespread adoption. But I have been using Dvorak since 1999 on a variety of platforms without a problem. It's a personal success for me.

"the trouble it is for them to manage different keyboard layouts in their head. I wonder if that's the same for dvorak layout users."

It's only on extremely rare cases that I've been forced to use QWERTY (such as at a public library) and when doing so, it hasn't been hard. So I don't have to manage different layouts in my head. I only use Dvorak, and my hardware and software supports it.

That said, I don't do any heavy typing on an iPad...

An on-topic but not well-known fact: "The present currency of Ecuador is the United States dollar."

http://en.wikipedia.org/wiki/Currency_of_Ecuador

Thanks for pointing this out, and I don't disagree. It's debatable whether TextMate was revolutionary or a huge leap ahead of the competition at the time. But batista claimed that "Textmate was always a sub-par editor" and implied that its success was due to hype, not its capabilities, which I find hard to accept as true.

I'm not claiming that TextMate was the best choice, just that it's unfair to call it a bad choice or sub-par. It was a very solid, decent text editor.

Community effects can never bring a poor technology to the top. They can keep a great technology from overtaking a good technology, though. But TextMate's success was not only from the community support, but also from its capabilities. Snippets were one of its cool features, for example, that helped it gain success.

Very good point.

This could still perhaps be solved technically, although it would take a lot of effort and is probably not worth it.

You can detect cheaters. People who give up/downvotes on the "value add" dimension that are not well correlated with the community's opinion of value add would be detected as cheaters, or at least detected as users who do not share the same values as the community.

Much harder to do, but possible, is to detect cheating in agreement by analyzing trends. Users who agreed with story A, B, and C may have a 90% chance of agreeing with story D. A user who bucks these trends enough can be detected as cheating or randomly voting.

"I don't think upvoting-on-agreement problem can be fixed technically."

I think there is a technical fix: two orthogonal upvotes. One upvote/downvote pair for agreement, another for whether the post/comment added value. It's a pretty simple fix and I think it would work, but it could have other unwanted side-effects.

> With regard to the "giving", I wonder what theories there are about why many people feel good when giving things up to benefit others.

Imagine two cultural scenarios: one where everyone is looking out for themselves and helping no one, and another where people are genuinely concerned with each other and eager to help when needed. Which culture would you want to live in?

I think we tend to by default project our motivations onto others (especially in the absence of data). So if we are primarily selfish in our motivations, we think the people around us are selfish. So my guess is that being generous makes us feel like the world is a generous place.

Also, our parents probably taught us that sharing with others is good. So we get a little psychological "stroke" of affirmation about our inner goodness by being generous.

The bunny or toaster example seems to me like someone still thinking in a statically-typed paradigm in a dynamically-typed language.

If you stop relying on instanceof and start using duck typing it would probably work out better.

Or maybe you should just never write a function called doThisOrDoThat. Seems like a code smell.

Well said. I think this is the best way of putting it. I temper my original position of saying that server-side view rendering is "on its way out".

It depends what you are trying to do. If you are only targeting browsers, and especially if you don't need a lot of responsiveness, it's much simpler to just render views on the server side and optimize your server for speed. It takes a lot of effort to write a thick client.

But if you are targeting a browser and a native iPhone app, the view logic lives on the iPhone app. It used to be that you could just serve up a web page and assume that your client was a browser. Not anymore, and that's my point. And my point is that the trend will continue: I think we will have more variety of non-browser clients in the future, not less. Your car, refrigerator, geranium, etc. will all be hooked up to the web.

Keep in mind that I'm not talking about whether you should create your web app in Backbone.js today, but I'm looking years into the future, anticipating trends.

Thanks for the courtesy of a constructive discussion. :)

Yes, that's a valid point, if you mean that smartphones have less resources (memory, CPU) to handle JavaScript execution. But keep in mind that a native smartphone app is a thick client; it has all of the view logic.

Perhaps I need to back up and explain my point better. Maybe people are misunderstanding me because they think I'm talking about what's going to happen in the next few months. Server-side view rendering is not going anywhere anytime soon. But it's on its way out in that it's an anachronistic way of thinking about the web; it's a relic of the past--of the time of web "pages"--and not of the future, of web "apps" and "resources". As long as you are serving content that's primarily to be "read", like articles, books, blogs, etc., server-side rendering has its place.

But look what's happening to the web. Native iPhone apps have to store their data somewhere, so they communicate to the backend via an API. Cars are reading Twitter. Thinking about the past of the web, only browsers consumed web content. Now non-browsers consume web data via APIs, and I see this trend as increasing.

I see a trend where more web apps will be like a "smart database in the cloud", meaning they hold data and business logic and communicate via JSON APIs. There may be a variety of client devices accessing this data in the cloud: native iPhone apps, desktop browsers, other Internet-enabled devices.

The main point is that clients are no longer only browsers. The clients could be a variety of devices running on a variety of operating systems. So it doesn't make sense for the server to render the view and send it down the pipe for the client to display. It makes more sense for the server to send data to the client and the client to decide how to render it.

I'm not claiming that server-side view rendering will go away completely; it has its place with articles and blogs. But with apps, I see a movement toward thick clients and I don't see this trend slowing down. It's hard for me to envision a world in 10 years with less smart phones, less devices hooked to the Internet, and people only accessing web apps and web app data with browsers.

Let me also put this in context of the article's original point, that PHP has a nice feature of being able to be embedded directly in HTML. Yes, this is nice. But my point is that if you are starting your web career and therefore are looking toward the future, the types of web sites that will use inline PHP will be more like content sites and less like web apps. And I expect a bigger demand, higher pay, and arguably more interesting work for web app creators than web content site creators.

I'm really not sure why this is being downvoted. It's not trollish. I believe what I'm saying to be true: mobile is increasing, and this is leading to thicker clients and more JavaScript and therefore less server-side view logic. Please correct me if I'm wrong, but downvoting me is confusing.

Agreed, it will be hybrid for a long time, but I expect the trend toward view logic being more on the client and less on the server to continue, simply because the web is less and less about "pages" and more and more about "apps" and "resources".

The Rails MVC architecture is already past its prime, since it solves the problems of 2004. It's possible that startups may move more toward backend-as-a-service + JavaScript front-end instead of using Rails as their MVP.

In any event, the transition should be slow and I fully expect Ruby to be around for a long time, but people may notice a slow decline in demand for Rails programmers in the next few years compared to other hotter technologies. Sinatra (or some other Ruby framework) may replace Rails as a backend.

I'm a Rails programmer and I don't bristle at the suggestion that market demand changes. I welcome the change and adapt. I don't mind learning new languages.

We really need a quantum leap in language technology. Currently the Internet technologies have grown organically and because of this, most of what we use to program has been repurposed.

HTML was meant to describe text, now it describes regions of the screen to be repainted as well as the "content" to be repainted.

CSS was meant to add simple effects like bold, italic and simple newspaper-like positioning (float this image left). It's been repurposed to describe visual rendering and even animations.

JavaScript was meant to add some scriptability to the DOM, and now it's morphed into a full-fledged programming language.

So the state of the web is a depressing mishmash of old, repurposed technologies.

It would be nice if there were a programming language that "knew" about the web. It would realize that the programming effort would be shared between two computers, client and server, and would have appropriate security and other conveniences baked in. For example, you should only have to describe your business logic once (as opposed to once on the server and once on the client). Also, this programming language should no longer be tied to the anachronistic concept of rendering a "document" with "styles".

But alas, it's very hard to simply go into an academic tower and design a language and release it into the wild and expect it to catch on. These things tend to grow organically and incrementally. So whatever next step there is has to embrace where we currently are. This is why you see not merely new client-side languages, but new languages that compile to JavaScript. If they didn't compile to JavaScript, how could they ever be used?

It's hard to predict 10 years out, but not too hard to see 5 years ahead. Generally speaking, what's popular now existed in some form 5 years ago.

JavaScript has a monopoly as the only language that runs in browsers. If this were to change, it will take years, not months, for browsers to start supporting another language (or go to a bytecode model). Then it will take more time for developers to start using these new languages and then an ecosystem of tools and libraries to form around this. Then it will take even more time for the "old" language JavaScript to seem obsolete.

JavaScript is currently gaining traction and is the lingua franca of the client-side Internet, which is growing. This is why I predict it will still be strong in 5 years, because it's got a lot of momentum and I only see the trends as increasing (mobile devices are increasing, browsers are becoming even more like operating systems with memory management etc., JavaScript as a language is continually being improved).

It's not a fad. It's driven by the increasing growth of mobile devices ( see http://www.digitalbuzzblog.com/2011-mobile-statistics-stats-... )

The Internet is becoming more ubiquitous. Being "on the Internet" will mean less and less being in front of your computer. The proliferation of devices you can access a web app from is increasing (smartphones, tablets, more coming in the future) so it is becoming more useful for web apps to be like a "smart database in the cloud" and for the view logic and code to be on the client.

If you are just starting out as a web developer and aren't planning on changing careers anytime soon, the #1 language you should learn is JavaScript. It, or languages that compile to it, will still be in fashion in 5 or even 10 years. That's because the web is shifting to thick clients, and JavaScript is the only choice in browsers. JavaScript is also finding its way into server-side code (Node.js).

"I think PHP is the perfect language for beginning web development for two reasons: Direct HTML embedding."

Server-side view rendering is on its way out. So this is not a real advantage.

"I find it more than a little strange that PHP is simultaneously (a) out of fashion, and yet (b) absolutely everywhere."

This is simply how technologies rise and fall. By the time a technology is ubiquitous, the original problems it solved have changed and new solutions are being created. Just because you have a bunch of legacy code running lots of web apps doesn't mean it's the future--it means it's the past.

Also, why pick a language that pays poorly? Ruby is by no means inferior to PHP, and you will get paid more per hour to program in Ruby.

It's hard to do advertising well where the interests of all parties are aligned. I think Google did a very good job with this, since the ads it serves you are more likely to be genuinely helpful to what you are trying to do. Most Internet ad models revolve around interrupting the user--being blind to the user's goals and point of view. Compounding this problem is that users often find it creepy when ads do know about their goals and point of view. Someone needs to creatively disrupt the current "off-topic interruption" vs. "on-topic privacy invasion" ad paradigm.

Velocity is imperceptible, since it depends on a frame of reference. For example, I'm traveling at about 700mph around the center of the Earth because of the Earth's rotation.

Acceleration is perceptible, because it is felt as a force. So it really depends on how quickly people are accelerated to 2500mph. If you accelerate at 22mph per second, this is equivalent to 1G, which could be relatively comfortable. It would take 2 minutes to reach 2500mph.

They are, last I heard.

Interesting. The arrow keys worked for me to flip the pages. Google Chrome + OS X.