rcoder

The entire model looks to me like it never had even the most superficial security analysis done. It's like a smorgasbord of insecure decisions:

* the false sense of security from putting signatures in the manifests then ignoring them

* loading signing certs via the network with no provision for pinning

* happily loading untrusted/unsigned images by default (npm, rubygems, installtools, etc. also do this but why repeat their awful design mistake?)

* running basically everything as root (because why deal with all those messy permissions?)

My sysadmin Spidey-sense has been tingling at the rate of change in the Docker ecosystem since it went from "interesting POC" to "we think it's production ready" in a shockingly short period of time. Things like this sadly confirm that initial pessimistic view.

I'm not sure how your Maybe type representation would help with the OP's concern about SIMD optimization.

It's a theoretically clean approach, but this article is largely focused on how to keep the (SIMD-aware) compiler humming along on large vectors without reverting to scalar operations.

AFAICT GHC only has experimental support for SIMD optimizations anyway, so this is probably less of an issue for Haskell code than it is for C/C++/Fortan numeric primitives (and languages like Julia which utilize them).

Like traditional BBQ (e.g., low-and-slow cooking over coals) sous vide is most interesting when applied to meat, especially cheaper cuts that would normally have to get boiled, braised, or roasted to within an inch of inedibility before being soft enough to eat.

That being said, my absolute favorite thing to prepare sous vide is carrots. Lots of other root vegetables (turnips, burdock, sunchokes, new potatoes) can similarly be cooked in a water bath to a temperature just high enough to soften them without extracting flavor or nutrients via boiling, steaming, or sautéing. I've also had good luck with green beans, asparagus, and broccoli rabe.

Finally, if you're pescetarian seafood is also a great option. I'm not sure I'll ever cook lobster any other way after seeing what whole (shell-on) lobster tails are like cooked sous vide with a healthy dollop of butter.

Mounting your database storage volume via NFS seems like a surefire way to cause yourself pain down the road. You might want to review the following (old but still relevant) article to understand some of the pitfalls:

http://www.time-travellers.org/shane/papers/NFS_considered_h...

The tl;dr basically boils down to the fact that PostgreSQL and MySQL (or really any good database engine running on *NIX systems) make very strong assumptions about the POSIX-ness of their underlying filesystem: flock() is fast, sync() calls actually mean data has hit disk, etc.

Docker/CoreOS/etc. aren't a replacement for a good SAN or other reliable storage. If you value your data I'd suggest keeping your core database(s) on dedicated machines/VMs (ideally SSD-equipped and UPS-backed). If managing those is too much work, consider a managed cloud database; DynamoDB and RDS can stand in for Redis and Postgres, respectively.

This, +1000: 'Isn't "no solutions that can be deployed with minimal security expertise" just about the whole point of this compliance?'

If you aren't a trained, competent security analyst/engineer (or working with one) then don't accept sensitive information. PHI, credit card numbers, even contact lists: all of these are considered "sensitive" for a reason, and you are being reckless in the extreme if you accept them from your customers without the proper protections in place.

I have seen and even been responsible for (many years ago) the implementation of some horrifyingly bad "security controls" by people who simply didn't understand the field.

It's not just crypto, or disabling root logins via SSH, or preventing XSS on your web forms; you need to plan for a multitude of possible attack vectors, internal and external. Many of those aren't likely to be intuitive without some real training and exposure to best practices.

This is the silliest argument for why intelligence would be negatively correlated with number of children. FWIW, the original article very much did not assert that assertion; reproductive success (meaning having any children at all survive the parents) in fact may be positively correlated because the social status of richer/more intelligent parents translates to higher survival rates for their offspring.

Regardless, while the absolute cost of raising children may be higher for high-income families, the share of their total income that represents is much lower. Someone earning minimum wage will struggle to support even one child's basic food, clothing, and shelter; their counterpart making $1M a year could easily afford private school, childcare, and the best possible opportunities for a family of 3-4 children.

I've used Joker since 1999 and have had nothing but excellent experiences.

They don't spam me, their DNS service is rock-solid, and their website (while a bit lacking in the graphical design department) is fast, clean, and ad-free. I also get clear, to-the-point reminders when a domain is up for renewal.

I have dozens (not hundreds or thousands) of domains registered, but I would recommend them without hesitation to anyone looking for developer-friendly registration and hosted DNS.

First: if you're building sites that people are using, you are officially a "junior web developer". That's especially true if you're deploying and supporting those sites.

Second: PDX.rb is a friendly, knowledgeable group. Find them on calagator.org and go to some meetups. They'll absolutely help.

I don't really do Ruby or Rails any more so I can't offer much more concrete help than that, but welcome to Portland regardless.

It sounds like you've had some terrible experiences with employers gaming your salary, for which I'm sorry.

As a manager, I value my long-tenured employees _very_ highly and work hard to ensure they get significant raises year after year. I learned to do that by working as an engineer at several other companies that did the same.

So, if your employer doesn't work to make their best, most experienced engineers feel valued and well-compensated, by all means look for another job. But don't assume that all companies will try to force you out as soon as your salary is higher than a new grad's.

I strongly disagree with this. It may be true at many companies, but not anywhere I would ever work (esp. as a manager).

Requiring people to have a competitive offer in-hand basically says, "if you want a raise, go interview somewhere else." That's toxic and only effective for the people who game the system.

Responsible employers owe their employees a fair (according to market, their peers, and their contributions) wage, not the minimum they can possibly get away with paying. It might save you a few bucks in the near term to play stupid games with people's comp, but the attrition will kill you in the long run.

I'd highly recommend fiction, history, and biographies. If you can, find things written about people and events in the region(s) you're visiting. Detailed maps are also great, because they let you go wander around and get a bit lost, then find your way back to wherever you've staying.

My usual media/gadget inventory while traveling is a compact camera, Kindle and a paperback or two, and a battery-powered speaker for listening to music at night. No headphones (too isolating), no tech books (distracting, and honestly frustrating w/o the Internet to do additional research) and only as many hours of video as I need to keep myself distracted during the flight.

Urban Airship is hiring systems and web engineers in San Francisco and Portland to join our 45-person engineering team. Our platform powers many of the biggest and best-known media, retail, and brand apps on all major mobile platforms.

We're a polyglot team (Java, Python, Javascript, Objective-C) and use open source (Linux, PostgreSQL, Hadoop, HBase, Netty, Django) wherever we can. We're supported by awesome ops, product, and design folks.

We care about massive scaling, great UX, building high-quality systems, and learning from each other every day. Remote (US) work is okay, and anyone with a unique origin story is highly encouraged to apply.

Email me (lennon at urbanairship.com) for more info if you're interested.

If you're running a vulnerable version of OpenSSL and want to be truly careful, assume your private keys (not just certs) are already compromised. Once new packages are available, you need to update and then re-roll your crypto.

Also, if you're using those keys to protect other secrets like passwords - say, DB credentials or AWS keys stored in an HTTP-hosted Git repo behind - you can't really assume those are safe either.

Fun times!

Think "working-age adult" (perhaps even "household") not "individual". Also, assume that taxes will reclaim that basic income from folks making significantly more than the poverty line.

According to Wikipedia, only the bottom quartile of the US population earns less than $22500 per household; if you assume that BI isn't simply added on tax-free to higher-earning households' net income, that makes it more like 1/4 of the 80% of the population over age 14 would be eligible for full BI benefits. So, call it 20% of your original population estimate.

That makes it roughly $600 billion, with the potential chance of largely replacing welfare ($532 billion* in 2013) and federal disability ($166 billion), not to mention some portion of Social Security and other programs.

Sounds like a reasonable idea to at least explore IMHO.

* per charts at usgovernmentspending.com

If you want to interact with local hardware/storage media, native apps are still easier. "Offline" mode can also be the default, at least for systems that have a local data store. Finally, multicore CPUs may be theoretically exploited with web workers, but it's a lot easier to just spin up a native thread in your Java code.

Downsides are all the usual ones, of course: updates don't happen automatically, you may need some sort of licensing/DRM if you want people to pay for your application, and your testing story is a lot more complex. (Plus: look-and-feel on various platforms, reverse engineering is that much easier, etc., etc.)

The cost of beer made on-premises is roughly half what vs. buying from a distributor. If you can create real demand for your product at your own pub, you can make an extra $100 per barrel (a.k.a. $50 per keg). At ~2000 barrels a year (which is 200 brew days per year on a _tiny_ 10 barrel system) that's an extra $200k added to your bottom line.

Yes, you need decent chunk of financing + equipment to get started. No, it isn't "real money" to most of the folks on HN. Compared to the margins on most foodservice businesses, though, it's amazing.

Generally speaking, the cost of scaling beer production is paid once. You need bigger, more expensive brewing equipment (and can't just repurpose mass-produced consumer items like turkey fryers and drink coolers) and the recipes have to be adjusted to the new capacity and setup, but your unit cost is much, much lower.

Surface area doesn't scale linearly with capacity, so both cost and cleaning time actually get _better_ as you scale up. Grain, cleaning supplies, and tools get cheaper as you scale, too.

It also only takes a tiny active culture of something bad to ruin an entire batch of beer. Each vessel, airlock, valve, and spoon is another potential source of contamination, so having fewer things to clean is a Good Thing.

Full disclosure: I used to work at Twitter, and this conversation came up all the time. I even proposed it myself as a naive new hire, and after a few good-humored suggestions from coworkers to run the math, ended up with roughly the following scenario:

Say 1% of Twitter's active users would be willing to pay for such a service. (That's extremely generous, I think, but it makes the math easier.)

At 240 million MAUs, that gives ~2.4 million paying users. Say the price was comparable to Flickr at $50/year. (Again, very generous, and probably out of reach of most users outside US/Japan/EU, but we'll try it for the sake of argument.)

After up-selling each and every one of those users, the company could have annual revenue of about $120 million...or roughly _half_ what they cleared in Q4.

Even with 2-3x organic growth in the next couple of years, it would be a dead-end in terms of revenue, and better-financed competitors would be able to push them around, poach their best staff, etc.

My $0.02: programming doesn't slot into a tiered progression of mathematics education as usually presented in secondary and higher education. At various times, it'll utilize concepts from basic arithmetic, trig, algebra, discrete math and set logic, and even topology and linear algebra. Trying to peg it against a normal math pedagogy is going to be a recipe for frustration.

However, it can be a great motivator to learn new areas of mathematics.

Consider a simple game engine: writing a program that displays sprites on screen and moves them will build an understanding of basic coordinate systems. Collision detection requires slightly more advanced math in that coordinate space. Pathfinding (say, for enemies chasing the player) requires all that, plus basic trig, plus some understanding of randomness and probabilities.

Particle behavior (for weapons, jump physics, etc.) begs for calculus. Error-handling can be a great intro to the difference between total and partial functions, etc. etc.

This was a huge motivator for me in learning mathematics both during my time in school and beyond. Instilling a love of problem-solving through coding is a great way to put your kid on the route to continuous learning.

Three things:

First, most recruiters/hiring managers ask for current comp (or at least a salary range) early in the discussion, so it should be easy for them to offer well over someone's current pay. This simply removes one bargaining tools (lying about current comp) for an employee considering a move elsewhere.

Second, matching outside offers very quickly becomes a slippery slope. Anyone who figures out that such a policy exists will quickly come to the realization that the easiest way to get a raise is to put themselves onto the market. That's toxic, not to mention unsustainable.

Finally, equity. The one-year cliff exists for a reason, and if you're playing for keeps with an early-stage startup, you're probably expecting (or at least hoping) for your ownership stake to be worth a lot more in the long run than your salary.

This is exactly the position I would take. However, I have little doubt of my ability to find another job quickly (and the resources to weather a period of unemployment fairly easily) so doing something that puts my job at risk in service of my principles is a relatively easy stance for me to take.

For those who have less-portable skills, or are in a more competitive labor market, telling your boss to go to hell is a much more dubious choice.

Having been a part of similar conversations to this at Twitter, I can say with complete confidence that you are wrong. The "...in a way that makes us proud" part of that company value is taken very, very seriously.

Yeah, I realized it was hyperbolic immediately after posting; hence the edit to say "tens of thousands of dollars".

I also wasn't really trying to generalize; I was attending a fairly expensive liberal arts school (albeit to study math) with 100% need-based financial aid, and tuition alone doesn't cost nearly as much at most state schools.

This closely mirrors my experience, though my "summer job" straight out of my Freshman year of college was part-time cashiering at a pizza restaurant. From there, I temped as an office worker at a startup, convinced them to hire me full time and let me build databases, then pivoted that into writing Java code.

After a year of work wherein I made about $25k, I talked to the financial aid office and found out that my expected contribution towards tuition, room, and board was likely to go from about $5k/year (barely covered via loans and family support) to $15-20k, which was totally untenable.

My response was to drop out, keep coding, and figure out how to backfill the CS knowledge I needed by working with smarter, more experienced people than myself. 15 years in, it seems to have worked reasonably well, and I'm regularly reminded how much easier my life has been not having tens of thousands of dollars worth of student loan debt hanging around my neck throughout my 20s.

To be clear: I know that the plural of anecdote is not "data", and I don't want to suggest that the dropout -> tech industry path is easy or in any way guaranteed. However, I think that it's a far easier field to get into than many others if you have the aptitude and motivation to build some things on your own and learn as much as you can from the process.

This is exactly the model that my team uses. We have ~40 folks on-site in SF, and about a half-dozen who work remotely. We got a Double a few weeks back, and after a slow start it's now in use most of the time.

The OP is not wrong about the qualitative difference between a 'bot and a normal video-conference setup. Things like this may seem minor (or even silly), but they go a long way to make it feel like our remote colleagues are actually present and part of the team:

https://twitter.com/thedeepg/status/337352680840257536 https://twitter.com/rcoder/status/336584756147916800

What you need for sharded queries is concurrency, not necessarily asynchronous requests. Async callbacks (ala Node.js, Twisted Python, Event Machine, etc.) give you a kind of cooperative multitasking, which is one way to have concurrent I/O-bound tasks going; multithreaded programs are another. (Ruby and Python threads are kind of in-between, due to their respective GIL limitations.)

That being said, above a certain scale and complexity level, you probably want the topology of your persistent data store hidden from your web request handlers anyway. For one thing, making requests to N backend shards from M frontend web workers starts to get bad when N and M are both large; for another, introducing really complex scatter-gather query logic into your request-handling pipeline can be a maintenance and debugging nightmare.

Introducing a proxy or data-abstraction service in between cuts down on the number of open connections and lets you change the data storage topology without updating frontend code.

A number of years ago, I set up a similar configuration with two OpenBSD boxes (which support PF and CARP out of the box) running Apache + mod_proxy_balancer for really granular load balancing and routing. It was a super-flexible and cheap way to route traffic to a mid-sized app server cluster, and generally worked really well.

We did have some network issues after the new topology went live that we unexpectedly tracked down to the LB pair, for one simple reason: CARP generates a lot of multicast traffic. Depending on how your hosts and network are configured, this can easily get routed out into a fairly large portion of your local network, and use a lot of bandwidth/router capacity with no benefit.

So, if you're setting up a CARP pair/cluster of your own, pay close attention to your multicast setup. Ideally, put the CARP multicast traffic on a dedicated subnet and watch your router and switch stats to make sure you aren't flooding the rest of your network with multicast spam.

Your instinct sounds solid on this one. From what you've said, I think going into debt now to change the focus of your bachelor's degree would be a bad idea. Focus on building your skills and experience at work, and I don't imagine you'll find the lack of a CS focus in your degree program will hinder your chances down the road.

From my POV as a hiring manager a CS degree is far less important than a proven history of shipping working code. If you're already in the industry, contributing to open source, etc., you can accomplish a lot more in 18 months out in the field than you could in school.

However, if you have gaps in your CS knowledge, it may be easier to fill them in school. Once you're coding full-time, it can be hard to find the time and motivation to explore as diverse a set of languages, data structures/algorithms, and tools as you are (hopefully) exposed to in a solid CS program.

As someone who just moved from Portland OR to the Bay Area in order to take a "corporate" engineering job in SF (and got a >40% raise in the process) I can say with confidence that the cost of living here, even outside the city (specifically Berkeley for me) is easily 2.5x what is was back in PDX, even with a 60 minute commute and meals comped at the office.

It's not just housing (which costs easily 2x what it does in or near any 2nd-tier tech city) - transportation, food, and mundane but pleasant things like pints of microbrew and movie tickets are way more expensive, too.