unshift

ah - you don't live in massachusetts then :-)

why? i'd rather keep the money than give it to the state. why vote for people who want to tax you more? i realize it's nice to believe in integrity but i don't think this is an example of it

> People who take internship opportunities from emails they receive are usually too lazy to look themselves, which probably shows a lack of drive. I say usually, because this isn't always true.

that's a ridiculous line of thinking.

emails are sent to department heads because outsiders typically deal with them often and don't have a relationship with the students. the emails are then passed along as a service to everybody.

what would a student with "drive" do differently to find an internship? walk door-to-door carrying 100lbs of stones in a backpack to submit applications?

a couple notes on the app store page:

the testimonial paragraph is awkwardly worded ("... a portal into a virtual shooting gallery overflowing with beach ball-shaped targets just waiting to be popped") and i can't tell how to play (or what makes it fun) from the screenshots. it's gyroscope controlled, but what the hell does that mean?

i'm going to give the lite version a try, but the app store page totally didn't grab me.

i thought "the heist" had a pretty good write-up and screenshot section, for what it's worth. i usually just read the first paragraph and scroll to the screenshots.

EDIT: i tried it, it's like an FPS where you shoot beach balls and twist the phone around to aim. looks pretty well done, but not my bag (i hate aiming anything by moving the phone)

i'd actually much prefer a lot of handy libraries (e.g., boto comes to mind) be written in C, and exported to higher level languages.

that way, each language wouldn't have to duplicate every other language's effort. the end result would probably be more unified APIs and more complete libraries.

tl;dr: don't give your password to anybody. we've been saying this since the mid-90s but people still seem to slip up.

gmail's two-factor auth is nice and easy with the handy iPhone app. of course nobody wants to complicate something like sign-in, but email integrity is very important. facebook also has a similar two-factor auth process (though not as nice; they text you, vs a nice app).

two-factor is a no-brainer at this point for managing your identity, especially given the huge volume of leaked passwords we've seen in the past month. it only takes a few minutes to set up and almost completely eliminates problems like the one in this article. if you haven't set it up yet, do it now! much easier than learning the hard way.

i thought the same thing. i spent a confused minute trying to figure out which units the 20/40 on the google analytics graph represented, given $1100+ in spending.

$250/day and on no day did facebook generate more than 40 hits. i would not consider that a success.

if facebook ads are good for "brand awareness" would it make more sense to use CPM ads with some sort of logo and/or memorable copy? they seem to be a bit cheaper.

i don't buy it.

haven't people been saying that since the 70s? even SQL was designed with the intent that accountants could use it. but programming is really hard, especially if you want something that's done well.

i've also yet to see any general purpose robots that can do anything useful. i still think it's a long way out, if at all possible. there are tons of considerations that go into just about anything and if there's no magic AI there's really no way to program every useful (nevermind adaptable) constraint into everything.

i don't think anyone thinks it's a solution to the general problem of concurrency. it's an evented framework, much like django is an MVC web framework. use of either library is pretty pedestrian.

twisted made a few innovations (Deferred, @inlineCallbacks, push/pull producer API) but all in all select loops are not new technology.

node is getting way too much credit if you ask me, but i think it's mostly because it's exposed a generally naive class of programmers (javascript coders) to a different paradigm. C programmers have known about select() for the last 30 years.

C++ has asio, now part of boost.

i have a bit of experience with twisted and must say it's pretty world class. it has great streaming APIs, really convenient APIs for working with processes, in addition to a solid networking library where you can either build your own protocols or use existing ones.

to say "it failed at scale" is ridiculous. i can point to a number of institutions with plenty of twisted code in production, moving hundreds of GB a day of data.

the only reason it would seem "failed" or "obscure" is that node.js has a huge fad aspect to it where people blog about and evangelize it constantly. most things in software don't have a fraction of the hype or exposure but that's not really due to technical shortcomings or lack of use.

http://lulzsecurity.com/ is still up

for updated-infrequently-if-ever repos, github's pricing doesn't make a lot of sense. i have plenty of small, one-off repos i'd love to back up on github but it doesn't make sense for me to upgrade plans for them.

i just back up to multiple boxes, but i can understand why someone would want something centralized and specific.

you can do pretty well with 1-2 processes per site; if you don't have the traffic to warrant it, there's no reason to run more. gunicorn can also use an async worker type (gevent) which can help keep the number of needed processes down.

django also has a sites package, so you can run multiple sites per django instance. it's less encapsulated but if you run a high number of websites with a low amount of traffic each it makes a lot of sense.

when i'm working a 9-5 job, the last thing i want to do is go home and program more. i'd rather throw the ball around with the dog or rock out on my guitar.

in my experience the people who say "you have to have side projects to be a good developer" are either people who do program in their spare time, or people who want to hire the type of programmers who voluntarily chain themselves to their desk.

this is one myth i'd really like to see die. good accountants don't balance checkbooks in their spare time, do they? lawyers don't hold mock trials, doctors don't do surgery on their friends as side projects, and construction workers don't pour concrete for kicks on the weekend.

the place i used to work prided themselves on having a large puzzle collection that candidates had to suffer through before even submitting an application.

i wanted to work there, so i put up with it, and write a fairly decent solution to a problem. took me about 10-15 hours by the time it was written and tested. "make sure it scales", said the doc. ok, async i/o and home grown select() loop it is! all this just to submit an application; no guarantees of even a phone screen.

fast forward a couple months, i'm sitting in the office with my team, and the subject of the puzzle comes up -- i asked if anyone noticed anything about the one i submitted. NOBODY HAD LOOKED AT IT. HR didn't even send it over.

probably the last time i'll ever do one of those. they're supposed to attract "passionate" people under the bullshit guise of "we'd like to hire the kind of people who like to do these puzzles in their spare time" -- code words for "we'd like to hire the kind of people who want to live at the office"

once i wanted to serve a quick and dirty page of 200 thumbnails but python's HTTP server choked after a few people tried it concurrently. it's single threaded and just wouldn't hack it.

luckily if you have twisted installed, you can run "twistd web -n -p PORT --path ." it's just as easy as the basic HTTP server but way faster.

is there any good way to avoid using IDs as selectors?

i'm working on my first large web project in a while. i'm using Compass/SASS (looks like you are too, or at least blueprint) to try to make things easier but i am finding that the HTML/CSS part of this site is such an incredible time sink.

my approach has been coupling the HTML and CSS almost 1:1 except where there are obvious re-use cases (which i'm not yet great at identifying, two pages in). this is probably bad but is there really a better way? i'm finding everything needs its own div in order to be positioned correctly across browsers and so i end up with container divs, then inner divs for padding purposes, then divs for each element, etc. it's a mess.

and don't get me started on the complete impossibility of consistent selector naming scheme...

amazon does that. you can browse the site and it identifies you and your preferences, but when you go to check out or modify account settings, you have to enter your password.

is anybody really doing this in the real world? it seems kind of inefficient to go through 15 testing cycles to write 10 lines of dead simple code.

i like to write tests before my code when i am trying to solve a specific problem, or think of a new potential issue and want to test it, but i find "pure" TDD takes it way too far. i don't see practical use in exhaustively testing every single potential case for a simple wrapper around datetime. i do like the idea for really critical sections, but it seems way overkill for most code.

TDD to me seems, like most things, as a good tool to have in the tool box, but moderation is key. articles like this are helpful to describe the practice but tend to always prescribe it for everything.

This same thing happened in Colorado a few months back, and I think California has a similar bill on the horizon

no real tricks here, this guy just seems happy he worked on a team with professional standards. thorough testing like that is, while not the norm, pretty commonplace at most of the better places i've worked.

i probably would have regardless because i've been conditioned that way all my life, but i wish it wasn't the case. i'd have had a hard time dealing with getting a C, but looking back i wish i spent less time doing busy work for dumb classes and more time doing other things like chasing girls and having fun

the fact is i could have worked my ass off for an A in french class, or writing, or whatever, and years later i wouldn't remember the material regardless because i didn't care about it at all. in the classes i did enjoy and did want to do well in, the material stuck with me (partly because it's my job)

i kept a 3.2 which was exactly enough to maintain my scholarship. CS was a difficult major at my school and a lot of larger, easy classes suffered from grade deflation. a lot of times i decided to just take the B in classes i didn't care about.

i also did a lot of CS group projects on my own which led to a lesser grade but better learning experience. i put a lot of effort into learning material i was interested in and got good grades in those classes.

post college, my GPA has had absolutely zero effect on any facet of my life.

that bright green banner is really bright... i found it hard to read any of the text on the site.

i'm also not convinced -- i see a crowded laptop screen and a bunch of post-it notes but i don't see a screenshot of my "favorite device", so i can't get a good 1-second gist of what you're offering.

nit picks:

- "while you were out memos" should be "while you were out" memos (move quotation mark)

- i would take the first person qualifiers out of the copy (we take the ..., our app..., etc) and make things shorter and more concise.

overall:

- design looks nice, though it looks to me like a pre-made theme

- show your apps in action, in an uncluttered environment (note how most macbook images don't show the keyboard)

- strengthen and clarify your message

not to mention they give out more seatbelt and sticker violations at DUI checkpoints than they do DUIs

VMware, 2007-2008ish

according to the title and article i should be using G-WAN for my static files, which i've never heard of before. i know nothing about it other than it apparently serves more files per second than nginx, lighttpd, and apache. but, i should be using it.

do you really recommend operating like that?

they're all very fast. what do i do with the information presented by the article? what have i learned that will help me make better decisions about what to use for a given project? nothing, really.

they're not even worth skimming.

a while back when tornado (for python) came out, there was a whole slew of benchmarks comparing it to twisted. as a guy who uses twisted a lot, i was interested. all the benchmarks said tornado was faster by maybe a hundred or a couple hundred requests/sec and therefore was the superior framework.

the big question is, what difference does it make? not a single article i read mentioned the fact that twisted has a really awesome streaming API, has great TCP and UDP level support, has support for a ton of other protocols (and writing your own), or is insanely useful for non-web projects. i never read about a single feature tornado had either or why one is worth investing time in than another.

same thing for this "benchmark". i might as well write off varnish, since it serves fewer requests/sec than nginx, right? wrong! it's a different thing all together -- no mention of that anywhere in the article though. the author just says (in not so many words) it's a piece of crap compared to nginx.

i don't really see the point of these micro-benchmarking articles at all.

so what if nginx can serve a theoretically higher number of static files/second more than something else. are you actually serving that much traffic with no headroom in terms of extra servers and load balancers? do microseconds of computational time per request really matter when your outbound packets can get delayed by milliseconds in the network or dropped completely?

there are plenty of reasons to like one server over another, but is .0000000001 seconds/request overhead really one of them? http servers can have wildly different behaviors regarding HTTP streaming, working models, extensions, etc. how about the fact that varnish is a caching proxy that doesn't really replace something like nginx, lighttpd, apache?

he's also backing varnish with a ramdisk that takes 25% of his memory (for a 100b file, no less!) when comparing it to the others. probably not the best designed test out there.

> Again, keep in mind that this benchmark compares only the servers locally (no networking is involved), and therefore the results might be misleading.

i don't know why anyone would publish "misleading" benchmarks

i know it's less fun and there are no numbers involved, but what about a real rundown of some of the subtle differences between the servers and some of their more unique features (besides async/threaded)? that's something i would find useful reading, but i guess it's not as easy as firing up ab.