ryan_f

I agree also. I primarily work in Ruby but was pleasantly surprised with the updates for iOS 5. ARC support and the addition of storyboards really helped with the parts I disliked working with.

The only issue is that I would prefer to work with another editor. XCode just doesn't have some of the editor features I am used to with other IDEs.

I agree. I have seen rounded corners in Apps before but there were a lot other variables for usability.

That is great that they listened to customer feedback. I started using other providers because of handling everything through the iFrames and callbacks. They have a lot to offer, especially with the ability to create customer accounts. It is worth checking out.

I was hoping the article would be a little more informative and definitive according to the title. It is based on assumptions itself with a little theory behind it.

As for the statement - "The first is that the traffic coming in had JavaScript disabled. If this was the case then the JavaScript analytics software would not detect the incoming traffic and therefore would not be able to log the result at all." You can track incoming requests outside of javascript through the server. That is possibly what they had wrote.

I use Skype a lot for free. Who am I to complain that they found another way to monetize their service? If anything, all the developers here probably appreciate paying for a service. If I don't want the ads I can pay Skype for my service. And the title is a little misleading - very opinionated vs the actual article.

It's pretty cheap to host your rails app on a server such as Heroku and that takes minutes to deploy.

True, but in the case of the app I need to start a test server and such. Its those steps that aren't well documented and can cause confusion.

My apologies I wasn't too specific. I was meaning a controller through express. It's not as straightforward as you would expect with code buried throughout on how to set it up. This is a typical barrier for developers to not test as much.

I don't think they are perfect programmers. Heck, I use several languages and frameworks, whatever is right for the project. Knowing a language isn't a perfect programmer (we all know that). And to your point, that was the comparison I would make. Node is young so there is a lack of experience with it.

Try writing tests for controllers with Mocha. It isn't as simple as one might think.

I disagree with this. By the ecosystem being huge do you mean the modules and different gems? That in itself is modularized for having the choice not to use them. The availability is what makes it powerful on top of the simplicity to get it all running.

Node is by far not simple for a new developer or new teams running node. Projects tend to drift toward unreadable due to poor design, just try following people's callbacks. I am not saying this is Node's fault but it being young results in developers' lack of experience.

I very much agree on the drop in productivity. I was just contracted to help with a Node project and just getting up to speed has been difficult. This is not all node's fault since the callbacks and such could have been handled differently.

The better examples will be in a few years when programmers have more experience with Node and the projects' code reflect that.

I won't be returning back to Node after the project though because it reminds me of earlier days writing XML with Spring.

I would have no problem with the post if it was informational and demonstrated exactly what you said above. I felt it was a little flamatory toward the HN community as a whole when in fact it is just a small minority that was complaining. Just an opinion.

Very true statement! I've been a customer for a long time now and I also have recommended it to many clients. As I am sure a lot more have. I am curious what the answer would be in a poll.

This is the first time a post on 37signals has me a little put off. It seems unnecessary and slightly childish. It wasn't meant to show how posts on HN can contribute to their business but to shove it in people's faces. You would hope that smart people like them can figure out that a few people do not speak for an entire community.

I went the less port because it was being upgraded quicker with the 2.0 release. I've used both and they are both great gems. Both function pretty similar so don't be afraid of the LESS version, its still supported in the assets pipeline!

I agree with everyone else on using bootstrap. Besides becoming the norm there are a couple of steps using available gems that could make a beginner have an easier time setting it up. It could be a difference maker with someone's time.

Also, huge fan of this tutorial. It got me started with Rails a year ago. Best resource I used to learn rails.

If that's the case then I am happy about it. There's been a big push lately about editors and it swayed me to finally use VIM... and I love it! I am a lot more productive since the change. I appreciate all the content people are putting out there for VIM. I learn something new every day.

The first half of the video served as a good example of how the 5 Whys can lead to the root cause. That doesn't mean the other Whys should not be looked at as they were an issue at some level.

The second half was a little more confusing with proportion of time in solving the problem. I understood the solution but now how it directly related to using the 5 whys analysis.

After using other SDKs from other companies, I expected more than just JSON returned. There are simple things like raising errors that could be in the SDK. I'm sure it will be there in due time but not everyone has the same experience.

I am rooting for them and I am glad to hear others are having better luck than I was.

After integrating both, this is right on the money. WePay is great for what it offers on a basic level. Stripe is better with integrating with a site and its features.

I've had a different experience using their Ruby SDK and have not found it as friendly for developers. Their API is decently documented but their implementation for paying is dependent on redirects and URL callbacks. The ruby SDK provides little more than a wrapper for passing and retrieving JSON. Some may prefer this but I felt that I was reinventing the wheel.

I am staying with them for one project because of some services they have that no one else offers.

I am rooting for WePay but they need to work more on their SDKs to be developer friendly.

I am curious on the choices of the 5 companies to compare against. The amount of load a site deals with is an important factor when comparing uptime.

The best advice he had for getting up earlier is not to rationalize. If I give myself the chance to sleep a little more it turns into another hour worth of snooze. Jumping straight out of bed works every time.

I think every startup would love to have a talented designer to work on the logo (and also the site). Budget is always the biggest reason it doesn't happen as soon as it should.

I haven't gone down the road of using sites like http://dribbble.com and carbonmade.com to inquire about designers and their work. It seems worth the investment of time to get a good designer for the right budget. Design shops tend to be too expensive for startups with $150/hour average rate.