I feel like Prickly Pear is right. If you want a job now a days, if you don't know javascript or haven't touched front end (html/css), you disqualify yourself for so many jobs.

I mean, you can say that about not knowing C++ too, or Java, or any language - lots of different disciplines have "so many jobs". I think PP's advice could be more generalized (and I think he meant it this way) as "learn more widely applicable skills".


Unrelated: really interesting article about tracking down an iphone exploit with three 0-day attacks used by governments to monitor dissidents

The last company I was at was totally data driven and in the 7 years I was there never hired a database guy, we talked about bringing one in every once in a while but I don't think we ever did. We did do some consulting with a hadoop company to help un**** our hadoop set up but that was strictly short term. Which is to say, beware what niche you specialize in because it's bound to go away...

Yes but I also think a certain subset of webdev shops are waaaay more open to hiring self taught devs.

I think database jobs are probably on the opposite end of the spectrum, where no one will give you the time of day without years of relevant experience or if they're looking to train someone new they want a fresh grad.

You took that piece of a larger statement way out of context.

Almost all contracts, the number of direct jobs inquires are on the rise though. I am a direct right now but I'd do a contracting gig if the circumstances were favorable. Since I do embedded firmware type development that the type of work I am getting inquires about that.

I gotta learn prolog and haskell in a week fml

I've never learned Haskell but I remember seeing this once: http://learnyouahaskell.com/chapters
Prolog: LOL just end it now

I had an interesting phone call with a recruiter yesterday, which I suppose adds something extra to the whole skills assessment issue.

The short story is that she contacted me for a level 2 / 3 position. At the end of the phone call, she said she can't put my resume forward because I have no working experience. I then respectfully asked her why she contacted me if my experience is a problem.

She said that, first off, she reads 1000 resumes a day. Okay, so an honest mistake anyone who's scanned loads or resumes has made.

Second, most people she talks to don't send complete resumes, so when she does contact them, they often have more jobs, skills, and information that they didn't include on their resume. "I thought that, maybe at job X you worked with Python or something." No... I wrote exactly what I did: nothing more; nothing less.

So... no one is completing their resume? Why would people do this?

If that is the case, then, at a glance, no one is even showing their hard-won skills, which is another confusing variable in what degree of skills are missing.

A lot of jobs sites have you upload resumes, but then you find a job and forget about it years later. I have recruiters calling me about my resume that's two years out of date. So I suppose she could be running into that.

No, she actually called me because she thought that, maybe, maybe I did Python at a previous job. She said it was common for applicants to totally not add large parts of their job on resumes, so she has to ask if they used "tech A" in a previous job because they often have used that tech but don't say so for whatever reason.

I sort of feel sorry for recruiters knowing this information now.

Or she just lied to you...

You did say it was at the end of the call

Yup. People lie all of the time. Especially when it makes their lives easier.

I just list highlights and primary responsibilities. I normally don't list side projects that overlap with my primary job either.

I think it's mostly going to be just manipulating lists and I'm trying to find exercises to do but there isn't a lot out there

I have a simple little system that I use to manage database migrations. The base case has all the tables I started with, and then whenever I need to change anything, I write a new little migration. I have a little table that keeps track of which migration you're currently on. Works fine.

But I have sort of a question about it. The migrations apply only to dev environments, our staging environment, and production - this is not a case where there are like client databases in the wild that might be out of date.

Is it really bad form to alter history? Like for example I added a few columns a few revisions ago and removed them today. Would it be bad to remove them from the migration script that I made weeks ago and also remove the removals from today's migration script?

I mean I guess it doesn't matter but it's getting harder to look at the migration script and know what every table should look like. I think I'd *kind of* like there to really just be 2 things in there:
1. the "base" state
2. anything that has changed since the last release

Is that terrible, indifferent or fine?

probably fine, but if you miss something, like a view that was created between the add and removal you might run into an issue.

On a completely unrelated note, my company got added to hour of code this week, so I've been running around like a chicken with it's head cut off trying to be prepared in case we get a ****load of users on monday.

One of my developers thought we should set up varnish in front of our ngnix server that is serving up static files. So I did and then wrote a simple script to download a bunch of images. The results surprised me.

wrote a script to get 30 images totaling around 10Mb and measure the time it takes.
Nginx was always faster.

nginx 0.473787069320679
varnish 0.526026010513306

nginx 0.485960960388184
varnish 0.580269813537598

varnish 0.488193035125732
ngnix 0.658568143844604

varnish 0.484789848327637
nginx 0.534404039382935

Uh, varnish is faster in half your examples there?

ETA: but neither beats the other very definitively

doh, ****ed that up.
ngnix was the first in each group

I know for rails at least its default/common production settings will have nginx serve static assets itself. So it could be that nginx was already caching them for you

Sup dudes. Thought I'd jump in here to say hi. been programming for about a year and lurking this forum for a bit.

I didn't have any caching set up in nginx while doing the test.

I'm going to set caching up and redo the tests to see if it's any faster.

What do you think the truth was? I don't think she was lying at all. It was part of a much larger, involved conversation.

I probably don't understand, but why not maintain all of the transitions?

So there's a base state [0] and then a script that goes 0 to 1, 1 to 2, etc. Everything is immutable and you have a repeatable way to go from any state to any future state. This is maybe a standard way for schema evolution.

This doesn't really solve the other problem (validation of the present state) though. One approach (more work, maybe additional value) is to validate the end-state after each transformation (e.g. rolling back the transformation if it's wrong). This way it's also versioned with the scripts and enforced by the database as opposed to something more ad hoc.

I don't think there's any after-the-fact value to knowing the transition history, and this way in order to know the current state of the database you have to either
* go look at a presumably good database
* apply the transitions mentally yourself

I have *also* considered having both - all the transitions plus a "master" model. I have a feeling that they would dirverge over time. I could try to use something like sqlalchemy's introspection tools to verify that they're the same though.