duggan

"Perhaps" and "so far" are sort of the keywords here.

It was probably a combination of things at the time, but the important question is now, nine years on, is there a better way for Twitter to use its position?

Innovator's dilemma.

> Being able to get work in this field without a fancy background is still possible, but only if you have the right connections. Like I said: it's no longer sufficient to be able to do the job

This sentiment regularly comes up on HN, and I find it a little exasperating. Human interaction has always been an important part of career.

There's a subtle (or not so subtle) contempt for soft skills in these laments. You can write code and have fun, but if you want to get paid for it that's a career. As part of this career, you will produce software as a byproduct. However, the primary purpose of this career is solving problems.

You work in the sales department of your own career. Sell your ability to solve problems. Do not sell bits.

There seems to be some confusion amongst people who move from writing code for fun to writing code for money. Which is of course that they're not being paid to write code, but to solve problems. Writers and musicians usually don't get paid just to write or make music, they get paid to entertain. If you're confused about why you're being paid, you might start to think you're getting a raw deal.

Since I started writing software not because of any love for it, but to solve various problems I was having at the time, it's always sort of shocked me that some people manage to get so far into their careers without realizing what they're being paid for.

I quite enjoy it now, but rarely in the revel of pure creation. Usually it's from the satisfaction of a problem solved in a reasonable amount of time under well considered constraints.

I'd never really considered it before, but of course the author is correct. Control of an API is the control of a language, and as with 1984's Newspeak, control of language is a powerful tool.

Amazon's control of the dominant language to describe infrastructure (its own web services API), for example, gives it a competitive advantage beyond its head start and inertia.

Of course, an unused API is as apolitical as an unused language, and noting that an API is political due to its usage (and is more political the more used it is) may be a useful extension of the idea.

A couple of different takes:

"The best way for Pythonistas to think about Hashdist may be a more powerful hybrid of virtualenv and buildout." [1]

"HashDist is motivated by a functional approach to package build management, and features intelligent caching of sources and builds, parametrized build specifications, and the ability to interoperate with system compilers and packages. HashDist enables the easy specification of "software stacks", which allow both the novice user to install a default environment and the advanced user to configure every aspect of their build in a modular fashion." [2]

[1] https://packaging.python.org/en/latest/projects.html#hashdis...

[2] https://conference.scipy.org/scipy2014/schedule/presentation...

Agree on all points, particular about weighing up the pros and cons. If you have full control of your stack, I would say Omnibus is a waste of time.

It is without a doubt most useful when you do not control the environment where your code is going to be deployed.

Someone also pointed me to HashDist (https://hashdist.github.io/) which looks like another isolation framework, but written in Python.

Sounds interesting, I'm familiar with Nix, but not Guix. The core tenets of Nix really resonate with me, and you're 100% right in your parent post: this does not solve dependency management. It is a hack which trades long term reliability for short term stability and ease of installation.

It is not The Answer, it's just an answer until we (and I'm glad to see there are people like yourself on the case) can do better.

All of it together, while providing a relatively straight forward interface for the consumers of the package.

PPA's are a seriously killer feature. Easily one of the most important parts of the Ubuntu ecosystem. Not enough people realize it.

Judging by the general implosion of the PaaS industry, not enough to make it worthwhile.

It's a much more complex problem than most people think.

Somehow I doubt you or anyone else here is shipping respirators and cryovalves as side projects, and even if so, the context here is clearly web and infrastructure software.

> There is nothing worse than shipping a half-baked product.

Well, other than never shipping at all, which is, of course, the point ;)

I've certainly never worked for a company that did not have a laundry list of complaints about its software, all reasonably successful ones too.

And it usually only takes a couple of beers to draw the same laments from people working in the sort of companies a lot of developers aspire to.

If you think you've acquired a teachable, repeatable set of skills that aren't being taught then it sounds like you've got a gold mine on your hands :) As a relative industry junior (about 10 years) I haven't been introduced to a codebase that wasn't lousy. Certainly all were lousy to one degree or another when I left them, but they served customers all while drawing down the ire of developers (including myself).

> This is not because microservices-first is inherently flawed. This is purely a skill set issue. Microservices demand a greater skill set. A 'monolithic' approach puts much less of a demand on the engineer's skill set.

> The truth is that effective use of microservices (knowing how to build architecturally sound software) is way beyond the reach of MOST smart, senior level engineers that I've met in my career. If this sounds arrogant, it's not; there's a definitive architectural skill set that CAN BE LEARNED but that is missing from most software practitioners.

If this skill set exists, and almost nobody can or does possess it, then your argument is purely semantic.

Who cares if there's an ivory tower of geniuses out there spinning out perfectly formed microservice architectures in novel domains? We're talking about rules of thumb for practitioners here, not laws of physics.

Your glee in the baseless speculation that a woman was a) naive and b) lying to cover up some perceived indiscretion, is unsettling.

It's another example of the challenge women face in our industry, not to mention the overall culture of shame around firings.

The contract between operations and dev (as concepts, not as people) is in need of renewal.

To my mind, that was what "devops" was supposed to be, but it's been a bit of a dogpile in the years since the term gained popularity.

Systems are opaque to most developers, and many developers wish to make their software opaque to the system on which it runs. This is a failure on behalf of our entire profession, not any one group.

Infrastructure software is in a bit of a renaissance period, but it's very early days. Packaging software is a total mystery to most developers. I don't even need to back that up with examples, most of us can recall the last time we can across a well packaged piece of software with joy due to sheer rarity. I'd be very surprised to find the average age of a Debian maintainer was trending anything but upwards, and steeply.

Containers are being misused, but that's because the alternatives we've been building for ourselves have not kept up with the strong user experience narrative of web and mobile software.

We need to do better.

It's more directly comparable to https://mesosphere.com/ - so, an abstraction further up the chain than Chef of Puppet.

The general idea being that it creates a virtual operating system across multiple physical or virtual "hosts" and allocates application stacks (like containers, maybe) compute/memory/storage as required. It ideally handles fault tolerance and load balancing gracefully too.

I do like the "mass SSH" functionality that Ansible provides, it's something accomplished years ago with Capistrano, but I certainly prefer having it in Python (now that I've wrangled together a dynamic inventory interface to Terraform's tfstate files).

Shell is not what you want to go to for orchestration, but, essential as it is, I think it's a separate concern from managing the configuration of the machine.

You're absolutely right about being able to start small as a major point in its favour, though. Not enough infrastructure tooling accomplishes this.

I have a friend who, years ago, used to go about inserting subtly absurd photos into Wikipedia articles.

One that I recall was for the Refrigerator entry, which he seemingly innocently updated with a "better quality photo" of his own fridge.

If you examined the photo you'd spot that there was a guitar on one of the shelves[1]

[1] http://en.wikipedia.org/w/index.php?title=Refrigerator&oldid...

I agree that having standards and best practices is a boon, especially if they can be packaged up in an easy to use way. Like anything, Chef brings its own set of idiosyncrasies to the table. However, I don't like how it brings all of Ruby's idiosyncrasies along for the ride too.

If you're not immediately comfortable and familiar with both ruby and the quirks of its ecosystem, you end up investing a lot of time into getting a development environment up and running (and having it reproducible by other members of your team).

Most infrastructure tools, if they're any use, are rapidly evolving. Conway's law applies here, and the maintainability of Chef mirrors that of its ruby ecosystem roots - people tend to freeze dependencies rather than upgrade. That's an antipattern we don't need in infrastructure.

Honestly I just think we can do better. For me, I'm not sure (read: I really don't know, I'm not being facetious) the costs outweigh the benefits, but for someone totally new, perhaps it helps them get stuff done faster.

I should probably couch this in the caveat that I am using Packer and Terraform to control the infrastructure itself :)

So machines are effectively configured "offline", tested, and replaced. It's not enough though (usual things like databases and development tweaks like config changes are problematic) so I'm back into the world of config management to see how it can help.

Matt makes some good points, and we broadly agree on controlling infrastructure, I just think that most of the CM systems are inadequate abstractions - they don't go far enough, and it leaves them largely as convenience wrappers around shell, but ironically enough, usually without the debuggability of shell.

I've worked with Chef for years, and recently have started seeing what I can do with Ansible. For me, the major thing in Chef's favour was the combination of attribute driven configuration and integration with things like Test Kitchen and ServerSpec.

Chef requries buy in to the ruby ecosystem though, and that's just not something I want to expose non-ruby developers to (it's just too brittle), which is why I'm exploring Ansible. What I'm finding, though, is that for any reasonably interesting tasks, I'm still forced to execute "command" strings, which is not an improvement over shell, and gives people the false impression that it's idempotent (or even just safer).

Also most of these systems are trying to upsell me a centralized management system and UI, handing over the keys to my infrastructure, which is just not something I'm willing to do.

Edit: I'd also add that cross-OS portability of CM (if that's what you're referring to), in my experience, a bit of a red herring.

Automation is my day job and I'm still not convinced any of them is a significant improvement over a well maintained set of shell scripts and Makefiles.

One more piece of software on my roadmap that I don't have to build now, thanks Sentry!

Presuming a basket of infinite depth (since physical goods are otherwise a poor analogy for copyright infringement), a more accurate version would be the suited figure repackaging and selling a decorative basket of your free candy.

Can you clarify why you think the person repackaging the candy in this situation has a moral highground? Why are they not also "smelling some money"?

Barricade - https://barricade.io - Cork, Ireland (relocation package available).

Imagine a beautifully designed product that monitors your servers' security, alerts you of serious threats and tells you how to handle it. That’s Barricade.

Positions:

- Infrastructure Engineer [Starting at €45,000 and 0.25% equity]

- Frontend Engineer [Starting at €40,000 and 0.25% equity]

- Data Science Engineer [Starting at €45,000, and 0.25% equity]

What we do:

We are working at the intersection of amazing user-experience, advanced security and cutting-edge artificial intelligence.

Our approach to work is drastically different to other security companies.

Every discussion, every feature starts from the customer's point-of-view and from a design perspective. We work very hard on understanding the pains, figuring out what our customers want and ultimately give them what they need.

We don't understand why security products have to be so complex, ugly, expensive, and ill-adapted to today's application development and deployment lifecycle.

Our goal is to take these complex systems and completely abstract them from the user. Security is hard, managing and responding to security events shouldn't be hard.

See https://barricade.io/jobs.html for more information!

I suspect the original commenter was just using a topical example, but ok, let's say it's protests.

A very large number of people streaming might create a curation requirement, but that's all. You have someone reputable who is retweeting or directing people to the most useful feed (as happens already with breaking news events on Twitter).

You end up watching someone having a dialog with a police officer, or in the middle of a rush, or something. You feel a greater sense of connection knowing that it is happening right now.

The generalization of this point is "what's the case for live anything" which can be answered simply with "presence" or more broadly, shared experience.

Sport is only the most obvious example. Why doesn't everyone just record and watch the game at their leisure? Or just get the highlights? Sure, those are options, but the enduring appeal of live sport points to there being more to it than just consumption of information.

> I can't resist reminding you that 1 command from a sysadmin routing traffic to the wrong network was the cause of the last major outage there :)

If you're going to bring that up, I can't resist reminding you of that time you had poor sysadmins running up and down stairs with buckets of fuel to keep your servers running[1].

> I've always said this: the cloud isn't a good fit for us; do what works for you.

There are costs. Frankly, it appears Stack Exchange prefers to lay those on its people rather than its purse.

[1]: http://blog.stackoverflow.com/2012/11/se-podcast-36-we-got-h...

Barricade - Cork, Ireland (relocation package available).

Positions:

* Infrastructure Engineer [Starting at €45,000 and 0.25% equity]

* Frontend Engineer [Starting at €40,000 and 0.25% equity]

* Data Science Engineer [Starting at €45,000, and 0.25% equity]

We are working at the intersection of amazing user-experience, advanced security and cutting-edge artificial intelligence.

Our approach to work is drastically different to other security companies.

Every discussion, every feature starts from the customer's point-of-view and from a design perspective. We work very hard on understanding the pains, figuring out what our customers want and ultimately give them what they need.

We don't understand why security products have to be so complex, ugly, expensive, and ill-adapted to today's application development and deployment lifecycle.

Our goal is to take these complex systems and completely abstract them from the user. Security is hard, managing and responding to security events shouldn't be hard.

See https://barricade.io/jobs.html for more information.