ryanto

Uniform access principle is nice to have in JavaScript, a dynamic language like you pointed you. One of the nice things is it makes refactoring a bit easier. Imagine you have code that reads:

  person = {
    name: "ryan to",
    first: function() {
      return this.name.split(/\s/)[0];
    },
    last: function() {
      return this.name.split(/\s/)[1];
    }
  }

But you realize this could be harmful, so you want to change it to:

  person = {
    name: function() {
      return this.first + " " + this.last;
    },
    first: "ryan",
    last: "to"
  }

All of a sudden your code breaks because person.name needs to become person.name(), person.first() to person.first, etc. That is somewhat hard to track down/refactor in a large JavaScript code base, or any dynamic language code base for that matter.

Uniform access principle is, in my opinion, one of the selling points for implementing your own object model in JS.

This is interesting and certainly solves the problems mentioned in the article. However, it does introduce a whole bunch of new attack vectors.

Have you thought about the idea of selling the product as a machine that clients can run in house? Something that is only accessible to them, similar to how GitHub enterprise works.

Bots that scan code for syntax/quality. While these are useful they should not qualify as a complete code review.

If you are looking for talented programmers start contributing to some open source projects. You'll get to work alongside some very good people.

This could be problematic if the same user is logged in from multiple machines. Logging out from one client will invalidate all of the other sessions. For some web applications this would be seen as a bad experience to the user.

Another issue is old sessions may be deactivated once the user logs out, but all those old sessions suddenly become valid again when the user logs in again, since the time stamp field is now present. It doesn't prevent the issue the author is highlighting (that sessions can last forever).

I'm a fan of Ember.JS - easy to get started with, good docs, great community, really powerful.

SEEKING WORK

Ryan Toronto - New York City and Remote

I'm a consultant from NYC interested solving business problems with the right technologies and processes. I have 15 years of experience in a large number of spaces. I enjoy ideas and practices from Agile and Lean Startup. In the past I've co-founded a successful startup and lead small development teams.

Backend: Ruby on Rails, Node, PHP

Front End: Ember.JS, Backbone, jQuery, Bootstrap, Foundation, SCSS

Ops: AWS/EC2, Heroku, Apache, Nginx, Postgres, MySQL, Redis

Architecture: Full stack, API design, SOA

I'm available for both development and training.

Feel free to email me ryanto@gmail.com or visit my website for more information: http://codingvalue.com/

SEEKING WORK

Ryan Toronto - New York City and Remote

I'm a consultant from NYC interested solving business problems with the right technologies and processes. I have 15 years of experience in a large number of spaces. I enjoy ideas and practices from Agile and Lean Startup. In the past I've co-founded a successful startup and lead small development teams.

Backend: Ruby/Rails, Node, PHP

Front End: EmberJS, Backbone, jQuery, Bootstrap, Foundation, SCSS

Ops: AWS/EC2, Heroku, Apache, Nginx, Postgres, MySQL, Redis

Architecture: Full stack, API design, SOA

I'm available for both development and training.

Feel free to email me ryanto@gmail.com or visit my website for more information: http://codingvalue.com/

The problem with passing success/failure as options is they don't compose well. Try to write the twitter example in the blog post this way. Then try to abstract each step as a reusable piece. And lastly have a mechanism for handling errors at any step. This looks ugly and is hard to follow. Promises (or generators) provide an API for thinking about async code as composable parts, which leads to easier to understand functions.

JSON is probably a better format for describing data, but maybe not for document markup. Take the following code snipit:

  <p class="justify"><strong>hello</strong> world</p>

How would you represent this in JSON? Here is my guess.

  {
    node: "paragraph",
    attributes: [{
      class: "justify"
    }],
    children: [{
      node: "strong",
      content: "hello"
    },{
      node: "text",
      content: "world"
    }]
  }

There is a few things to note between these two examples.

In the XML version it is much easier to distinguish the actual content from the meta data. Right away we can see the p tag describing the content "hello world" with metadata as class/justify.

Also, since webpages are all text (we can view this as there is no data type) JSON may become less valuable. We don't really describe types well in XML, but that shouldn't matter on a webpage since it is only text. Where as in a data serialization format, like JSON, that sort of thing is extremely important.

I don't feel strongly about XML, but I don't think I want to use the same format for describing data as I do to describe my documents.

They are, which is why Ruby's Module (class comes from module) has attr_accessor method.

http://ruby-doc.org/core-1.9.3/Module.html#method-i-attr_acc...

The above can be written as

  attr_accessor :sanity

SEEKING WORK

Ryan Toronto - New York City and Remote

I'm a consultant from NYC interested solving business problems with the right technologies and processes. I have 15 years of experience in a number of spaces. I enjoy ideas and practices from Agile and Lean Startup. In the past I've co-founded a successful startup and lead small development teams.

Backend: Ruby/Rails, Node, PHP

Front End: EmberJS, Backbone, jQuery, Bootstrap, Foundation, SCSS

Ops: AWS/EC2, Apache, Nginx, Passenger, Postgres, MySQL, Redis

Architecture: Full stack, API design, SOA

I'm available for both development and training.

Feel free to email me ryanto@gmail.com

I have a stupid question. Has anyone ever been asked this in an interview? Or knows anyone that has been asked/asked this question? I've been reading a lot about this situation over the last month, but have never heard anyone say it happened to them or someone they know. Just stories that seem like rumors/gossip.

I do not know many people who are right out of college and interviewing (and that's who I assume would be asked this sort of question), so maybe my network is too small to have heard of it happening.

Also, I realize many people will sign NDAs about the interview process, I am not looking for juicy details of when/where/how it happened. I'd just love to know if people actually had this happen at one point in the last few years.

Interesting idea to use an April fools joke to raise awareness about probably one of the lesser known projects.

Ember is a lot nicer. If I had to sum it up in one sentence: More features that make life easier for the developer. If you are coming from Rails you'll agree with a lot of the choices behind the project. By that I mean the whole idea that convention is better than configuration, as long as there is an easy way to change that convention if need be.

In the last year I built three JS applications of various sizes. Two were in Backbone and the third was done in Ember. I really have nothing bad to say about Backbone, but I'll probably never go back to it again. Writing in Ember just felt great. I didn't really have to think about MVC or how I would design certain patterns because Ember supplied all of that to much. This made the project very easy to deal with when it was starting out and small, but also made things really easy when refactoring and as the started to grow in size.

Programming is hard. It is really really really hard. It can also be really enjoyable, especially those ah-ha moments when you figure out the reasoning behind a certain pattern/style/idiom.

You are dead right that callback spaghetti is a problem, but instead of blaming the language/library you might want to reevaluate your implementation. There are a number of ways to deal with node callbacks. This is an excellent easy to follow article: http://seanhess.github.com/2012/02/20/functional_javascript....

I wouldn't mind seeing a version of a the Github dashboard where my feed was grouped by projects.

I don't think having a timeline where you see all commits of all projects sorted by time really helps. The commits in project A don't effect the commits in project B, so they do not need to be viewed in sequence or relation to each other.

Let me have a dashboard where I can see all my projects then some recent/popular issues and commits to that project, keeping all projects separate.

Don't add a like/favorite/bookmark button, I think that's too many options. Watch already says "I'm interested in this", so we don't need additional buttons to express the same thought.

At the time of reading your comment it is light gray. I am not sure why people are downvoting you... _method is a pretty important part of the rails routing and solves a lot of the proxy/server problems that people are mentioning.

In fact, I would argue that things like put/patch/_method are what make Rails so great. Rails makes a lot of strong opinions (put, whoops no, patch!), but then at then end of the day always gives you a way (_method) to deal with any issues where their opinions may not work in your current architecture. This pattern appears throughout the framework and is one of the reasons I really enjoy Rails.

Work hard

Produce quality code you are proud of. Believe in what you are writing and why you are writing it.

Focus on making good decisions.

No, not at all. There is a spec for HTML5 and it is most certainly not 'next generation web technology'. It goes into great detail on a couple of specific features that browsers will aim to support.

The problem is that people often want the latest and greatest technology. Geolocation is a good example of this. They think because chrome is an html5 browser they can have geolocation and often are confused when you try to explain why that feature won't always work. "But it's part of html5!" they say.

Instead of bundling everything under "HTML5" I wish we could just talk about the actual features.

I agree with the gist of this article, but there is an opposite side to this piece as well.

We do need those developers that pick the most wild, crazy, and bleeding edge technologies. New technologies shouldn't and certainly don't solve every problem out there, but they often tackle a couple of really interesting areas quite well. At the very least they allow us to question and rethink our current development stacks. Also, being one of the first to adapt to a technology has it's benefits, not saying that it justifies the risk, but it should be considered.

Also I think node js and cassandra are pretty easily maintainable, but thats not really what this is about :)

Developers who lack skill are awful at picking technologies. I like to think of it like this: when the guys that don't know anything start picking the tools they are basically throwing darts at a board. Everything is going to seem random. Sure, some of their picks will be correct, but most are going to be awful selections that make maintaining the project a very unpleasant experience.

what?

your last: - 'you can strive to be unique in a one-person class that is more immediately profitable and scalable than a commodity programmer.' seriously?

if this guy wants to become an expert in the technologies he mentioned then why is that so wrong? if he enjoys programming and has the drive to get to the top then he should absolutely go for it. smart employers are going to appreciate and see value in someone that has spent thousands of hours coding.

None of the posts in this thread really answer the question to "why python over ruby", they just talk about all of the nice features of current python development. The thing is modern Ruby has all of those tool sets as well.

Before you even being to make the statement "Why are more Startups using Python over Ruby?" you need some data. I'd be willing to bet that more places do in fact use python over ruby, but that number is a lot closer to 50/50 than you think. In fact, it is probably so close that this argument becomes pretty silly.

I once heard a successful startup founder describe the choice to use Python over Ruby because a couple of years ago getting started with Ruby was too difficult for them. They had spent a day trying to setup Ruby, Rails, etc and nothing was going correctly. After that they tried to install Python, it worked, and from that point on code was written in python. This story isn't elegant, sexy, or thought provoking, but it goes to show you that there are all sorts of crazy, silly, and stupid reasons why some people pick one language over another.

Lets talk about reasons why startups are _NOT_ using Python over Ruby.

Python is not taught at more schools than Ruby. Well, I couldn't find a list of schools teaching Ruby, but search for the Python list (hint, its up on python.org). There are only a handful in the US and these look like nothing when you consider all of the places that use Java.

Python's syntax is not easier or better than Ruby's. Nor is Ruby syntax better than Python syntax. Anyone trying to compare the two is just looking for a flamewar. Omg significant white space vs lol meta programming type arguments.

Both languages have excellent documentation and community. Very hard to compare these sort of things.

Django is a great framework, but so is Rails. Both have very vibrant ecosystems that are just exploding right now.

Tools - great tool sets in both. If a Ruby tool comes out that is good you can bet your ass there is going to be a python port of it in the next few years (and vise versa of course). A single great tool is never bound to one language/framework.

Implementations - both languages have a ton of cool projects that revolve around finding alternative ways to rebuild the VM.

Go ask people why they chose to write in a language/framework. They are going to give you answers like "it's what we chose", "i dunno, we just knew it". Comparing things like documentation, community, MVC Frameworks, tools, syntax, etc with two languages like Python and Ruby is pretty silly because its going to become a wash every time.

How do the articles from this site always make it onto the HN front page? They're full of misleading information, are only written for the link/flame bait, and don't provide any good actionable advice.

I know news is slow these days, but this kind of posting needs to stop.

which is better: a hammer or a screw driver?

exit;

You mention that there are 2-3 times a year when you have peak traffic load. Do you exactly know when those times take place? If not, EC2 is great for automatically spinning up new servers when your load gets too high.

if you are building something small, like a two or so week project, then sure... skipping tests would allow you to get to the MVP faster.

the problem is that when you get to the 5th week you are really going to wish you had tests in place. making quick changes and then being able to run them against a test suite to ensure that everything is working correctly is valuable. this value goes up (in a non linear terms) as you add more and more code into the project.

to answer your question: at first writing no tests is faster, later on it becomes much slower. it is probably never better.

I guess I don't really get the point of this. The whole idea of ditching points was to see if it could generate better discussion. By using this extension you are re-enabling points (even if only for a few select users). That re-enabling is going to encourage those users to go back to their bad posting habits... or so we would assume if the original theory that points cause bad posts is correct.

I know a lot of you love your points, but maybe we should see if no points really does generate better discussion rather than trying to find a way to create a point system.

PS: I think points is really tricky, it rewards people for great comments, but it also rewards those stupid-one-line-no-thinking comments. Maybe only show points for comments with more text... whatever, thats a whole other subject.