willsulzer
Joined 15 years ago
Karma
14
Submissions
6
Member since
Dec 6
Recent submissions
Comment · 11 years ago
Comment · 12 years ago
I'd have to say this is very exciting, and something that from which the Ruby web community could benefit greatly. Having the boiler plate cases covered for data binding and synchronization across the client and server could really increase productivity for modern web application. For anything else that doesn't fit that mold, a developer could always degrade to using their front end framework of choice with Websockets or AJAX back by REST APIs where appropriate.
Comment · 14 years ago
Seattle, WA. King of the Web: http://kingofweb.com is looking for experienced Ruby on Rails web developers. It's a lean, mean startup and we have a blast! Drop us your resume: resume (at) kingofweb.com and mention Hacker News. More information on our jobs page: http://kingofweb.com/pages/jobs
Comment · 14 years ago
I agree with this article to the extent that we should choose our URIs carefully and semantically. However, it is very likely that your web facing application, and the semantics of your resources will change over time. What if I wanted to deprecate and eventually remove my 'Providor' or 'Style' resource? Maybe I decided to create a 'blogs' and an 'articles' resource. That would change the URI from http://www.w3.org/Provider/Style/URI.html to http://www.w3.org/blogs/articles/URI.html (I know that my choice of new resources aren't the most interesting but you get the point). Of course, we would still support the old URI via a 301 redirect to the new one, or continue to serve up the page from the old URI and use a rel canonical meta tag. I'd advocate for 301ing to the new URI and letting the past be the past. We shouldn't be bound to these decisions for the rest of our lives. Unless you're sure that the focus of your web app will never change, or you plan to build your new resource URIs around old resource URIs that were chosen at a time when your new resources weren't being considered (which would lead to far worse URIs), then I'd plan for your URIs to change.
Comment · 14 years ago
@codenerdz this is correct.
@michaelbuckbee You will have an option to choose a Ruby interpreter for each project. Just be sure to not use any interpreter that has '[global]' in the name and you'll be able to switch your gem sets seamlessly.
Comment · 14 years ago
I've been using RubyMine since nearly the first release. I started using the 'Ruby' plugin in the IntelliJ IDEA IDE for Java. IMHO RubyMine is far the away the best IDE for RoR development on the market today. Here's a few of my favorite things about RubyMine:
* Great dependency management. The source code of all your Gems is accessible/searchable and always present. If you're using a method in one of your external dependencies, you can 'command-click' through to the Gem source. * Full integration with RSpec/Cucumber. You don't need to break out of your work flow to run a test. You will be presented with a small panel that includes our test results and clickable stack traces of failures. * Good refactoring tools: Extract a variable or method from a code block with a few keystrokes. * Etc.. (the list goes on and on)
Given the nature of the Ruby language, the IDE can only do so much, comparatively speaking. The Java IDEA IDE is arguably more powerful than RubyMine because of the static analysis capabilities of the Java language. I'm not at all saying that I would prefer to develop in Java because of 'better' IDE support, it's quite the opposite really. RubyMine does a lot to increase productivity by making assumptions about how developers will use the tool that result in a very desirable RoR IDE.
I am on the Applications team. Blue Box has been a fantastic and challenging place to work/learn for the last 2 years.
The Application Development team is looking for highly motivated developers (all skill levels) to help build the IBM cloud. Our company manages the IaaS tier of IBM Cloud using OpenStack.
https://www.blueboxcloud.com/careers/join-the-team