Yeah I never got into Rails but I have used Sinatra. Which actually hurts me in the job market when people are looking for RAILS blah blah blah, but stuff like Sinatra really is better in a lot of cases.

FWIW, the technologies du jour here seem to be Java, C#, and PHP. I think Drupal is winning the PHP trophy. Those guys do some truly impressive work with it. Of course, there are quite a few Ruby and Perl people as well.

I find the thought of lowered ability interesting because that was a stated reason for houses actually dropping RoR and switching back to PHP or other frameworks.

Is it strange that I'd kind of like to find a job at a company that uses a very obscure (well non mainstreamy) but interesting language where I could start as a complete beginner and just learn, learn, learn?

Unfortunately companies using these languages tend to not look for people that want to be treated like total beginners (especially since I'd have that annoying and pesky PhD by then)

Like upgrading it in less than two weeks...:P

Unfortunately you're probably fighting stereotypes here. The common stereotype I hear of PhD candidates is that they're too academic and care more about learning than about getting **** done. Saying you want to start with something you know nothing about to learn about it - sort of reinforces that view.

Then again, most places using non-mainstream-y languages are probably much less prone to holding that stereotype.

Get a job at Oracle, there is probably someone there right now writing an internal version of Ruby in order to start a project requiring a web page.

Hey guise, just got this job description from a recruiter, looks like a great opportunity!


Job title: Front-End Developer

Job Requirements:
· Do you believe that JavaScript actually requires engineering and computer science techniques, rather than just hacking?
· Did you write your own JavaScript framework before the likes of jQuery or YUI took center stage?
· Do you relish in the intricacies of runtime DOM and CSS manipulation to achieve just the right UI effect?
· Do you live and breathe asynchronously?
· If you answered yes to all of the above, then this job is for you.

Minimum Qualifications: Must have:

· 2+ years of experience with object-oriented programming in JavaScript.
· Experience with AJAX and JavaScript frameworks like jQuery, YUI, Sencha or Dojo.
o We need strong experience, not merely “used it”. If you have contributed to any of these frameworks, it is a big plus.
· Proficiency with HTML and CSS and how to integrate in a standards-based fashion with each other and JavaScript.
o HTML5 and CSS3 experience is a big plus.

i don't think i would hire someone with a synchronous autonomic nervous system. "i'm sorry can you repeat that? i had to breathe and pump my heart."

i'm trying to decide if everyone lives asynchronously or if no one does. i probably answered this question on a midterm for one of my cog sci classes.

what is waking up but following a function pointer you passed in before you fell asleep?

Huh. I didn't know Drupal was that unstable. :/

@Shoe, relax, the guy was being tongue-in-cheek with that comment. Many developers think the religiosity of languages is partly pathetic and partly funny. He probably couldn't care less what you do with your time.

Lisper's, from what I can tell, seem particularly prone to picking on religious programming tastes, probably due the the perceived legacy of the language.

I think there's a little more to the story as well. In Influence, Cialdini talks about "earning your right to be in a club." Although he talks about the military and frat houses, there is a correlation to programming languages and the communities. So, to be part of certain clubs, you have to fight for the right to use the language effectively. Angular, Haskell, Clojure, Scala, and a few others fit this. The traits are mostly incomplete documentation and just enough help from the community to get you on your way, though nothing to useful. Even the well-intended stuff starts from "This is a response map, now make routes."

I think that once you start to over-explain and over-simplify, you do three bad things. First, you take away the exclusivity of the club. Second, you dilute the brand of the product. Third, and most importantly, you destroy the addictive joy of self-discovery. Many people want to feel the adrenaline of hacking the system. This is the allure of many programming languages, and the allure of vim and emacs. After a while the addiction wares off, but that addiction isn't going to happen at all if it is all too easy, or well-documented.

I've struggled with this in my own programming. I love working with Lisp and C, but it is telling that you can count on one hand how many good books there on these languages combined despite their age. I've considered writing super-simplified tutorial on things like, how to build a log in and comment form, but every time I get half way through, I stop. One part says it isn't that hard, the other part says no one else is doing it, and these people are clearly more qualified than I am, so maybe the community doesn't want it, and perhaps it is the way it should be. Finally, if a drooling idiot can figure this stuff out, why would someone with 5+ years and a degree need said drooler's help?

And to honor the Senate committee video:

https://github.com/EnterpriseQuality...erpriseEdition

I used to be one of those hipsters that used node early on, and dabbled a decent amount in client side frameworks. I did that for about 2 years back when node was in v0.4x. I didn't even touch rails until shortly after 4.0 came out a few months ago.

Eventually you get to a point where you wind up reinventing a ton of what rails gives you. Go look at node's eco-system. There's SO many tools that are nearly direct translations of some component in rails.

The only difference is you as a developer have to go hunt and peck through 15 different modules and setup your stack but now you have to also glue everything together in a way so that actually developing your application is productive and seamless between all of the moving parts.

Who is going to be able to write a more cohesive framework? You by yourself who is likely winging it per project or an entire core of extremely smart developers who have extracted and iterated on a framework for 10+ years?

I'm not even smart and it really didn't take long to figure out the things I needed to figure out for rails. The key was to not read a 600+ page book. Instead just try to do what you want and look up stuff as needed, then ask questions if you get really stuck.

I will say it is interesting to see you swing the polar opposite of how you spoke 6 months ago.

Glad you enjoy Rails. Certainly not for me, or anyone, to judge someone enjoying what they are using.

I would totally hire Shoe now if he was looking for a job.

Edit: Actually maybe not. I don't want people to know how much I goof off on 2+2...

Yeah about a year ago I was on micro.js picking out 50 libs to run a project while also making 1 function node modules. I was also super hung up on performance.

I'm not really sure what clicked in my head but I eventually woke up one day and just realized none of that matters to me at all and the only thing that matters is producing results.

We've come a long ways! If I do need a job I'll hit you up, but I'm ok for the time being. Thanks though.

holy **** dudes, shoe wrote this!

i haven't worked much with node but given javascript's... cavalier attitude toward scoping and namespaces, i can imagine this problem is especially nightmarish in that ecosystem.

Nice thing about this forum is that, despite the respectful bickering, you're bound to change your mind on a thing or two. For that, you guys rock.

So I'm about halfway through Robert Martin's Clean Code (http://www.amazon.com/Clean-Code-Han...rds=clean+code) and it's been a great read so far for myself, but I don't think it would be for a lot of guys with 5+ years experience.

I have a feeling more experienced developers (who care about their job) aren't going to have the aha! moments I've been having and loving. Although there may be something to be said for developers who know this stuff already, but don't necessarily practice it and the book will give them the push they need.

My aha! moments so far:

1. Naming variables, methods, classes, everything, is the most important thing. Going into this book I had no clue how important this was and it totally opened my eyes to the importance of having unique and descriptive names for everything, without being overly verbose.

2. Comments are inherently bad. When you need to use/put comments in your code, it's a matter of making them the least bad. Ideally, the code should read such that comments aren't necessary (i.e., naming sh*t right!).

3. Functions should do one thing and one thing only. A great example in the book that made the lightbulb go off for me was a checkPassword function, which took in the username and password, checked to see if it was right, and if so, initialized the session and returned true, else returned false. Then he showed how if someone else was reading the code and at some point checkPassword is called, without having read the function itself, the person reading the code would have no reason to assume it is ALSO initializing the session.

There's a few others but those are the major three.

----------

One other great example was some check to see if an employee was eliglbe for something...it went like:

if((employee.Age < 65 && employee.Position == X) || employee.Something < somethingElse)

and the author said just make a function which checks that, and then you have:

if(employee.isEligibleForReducedBenefits)

It may sound silly to a lot of you...but when I saw this...mind = blown.

Those are all great things.

I take great pleasure in deleting people's comments from code. Especially when its something like:

//Get employee's salary
salary = employee.getSalary()

I read once a rule that was something like your comments should only explain 'why' you're doing something and not 'what' its doing. It seems generally true to me.

Edit: My rule of thumb for conditional checks is that if I need to futz with spacing/alignment to make the check code readable, its probably time to move it to a method.

I'm really terrible at comments and over comment from habit. Am trying hard recently to not do it so much.

For the (weak) defense of what I sometimes do, for some reason it does help me think the process through (objectives, division of problem etc) before writing code but there's no reason I can't do that on paper I guess or improve my memory.

It's unclear if I've written a comment in my professional development career. I'm sure a few were warranted, but meh.

A really good point. I'd add a fourth here - it's easier to contribute to a new, obscure ecosystem that doesn't have it all together and contributors are by far the most loyal users, not to mention their importance in sustaining an ecosystem I mean, as Shoe mentioned, all you had to do become a major contributor to the node.js ecosystem in the early days was to look at what Ruby/Rails has and write an equivalent. Once a framework becomes reasonably mature, it's difficult to contribute to and not having as many people contribute means you're losing mindshare among a critical segment.

Yeah naming stuff well is amazing, it was an eye opener for me too at some point. Also thinking about your application in terms of abstraction points really helps with naming / making functions.

Even if you're the only one working on a project try to think about what would happen if you had 1 guy writing the functions and 1 guy using them to build an app. The goal would be to use those functions rather than litter your "application layer" with implementation details of those functions.

They really hit home with that concept in SICP.

I was lucky as my first professor was VERY insistent on proper naming, documentation, etc It has made coding so much easier.

1 and 3 are great. 3 extends to classes - monolithic classes are the suck. 1 is all about creating abstractions. Your function/class/variable name should create the proper level of abstraction based on the context.

2 I tend to disagree. The main principle is write comments to explain why you're doing something, not how.

Dunnu how stable it is, dunno the system at all but I keep hearing uprading (to 7?!) is a huge hassle for nontrivial sites.

This has always bothered me (even before starting my PhD) especially coming from startupy folks. Many PhDs are essentially the science counterpart to startups. Well I see the world this way and everyone sees it another way...**** them I'm right I'll just go ahead and show them.
Granted there's also quite a few "let me slightly improve this and do it in ONLY 6 YEARS!!" but then again there's plenty of lolbad programming projects as well. I think it's basically the counterpart to judging all programmers by some mindless corporate Javabots (or PHP cut&pasters).

On number 2. it would be appreciated if you could provide some context with an example. Thanks