81–90 of 146 posts
Bob > -Aphyr is that guy who wrote, ‘Call Me Maybe.’ You know, the distributed systems and BDSM guy?
Anne > What? Did you say BDSM?
Bob > -Yeah, BDSM. It’s San Francisco. Everyone’s into distributed systems and BDSM.
This hilarity demonstrates the tone, and alone is worth the price of admission. Great job with this article.
Earlier quoted context omitted.
Big platforms tend to be different things to different people. Might help to have a different "what is docker?" page for the various roles you encounter. For CIOs: click here For developers: click here For sysadmins/devops: click here For platform providers (e.g. heroku): click here.
Whenever I see a product segmented that way, I'm immediately suspicious. That much work means that a) they're trying to sell something because it isn't obviously better and b) they're more worried about messaging than being simple and useful.
In fact, imprecise or unclear messaging is usually a red flag.
Earlier quoted context omitted.
The problem is not that they "message themselves" (gross) wrong, but that they feel like they have to "message" at all. Sales & marketing mumbo jumbo has no place in devtools -- it is at best, obfuscation -- at worst, misrepresentation.
Devs are people. Getting people to use things requires communicating to them what the things is for, and how it is better than other alternatives, and how to use it to realize that benefit. Therefore, devtool adoption requires messaging related to what the devtool is for, how the devtool is superior to other alternatives in the same space, and how to use the devtool to realize that superiority. Actually having the to…
Anyway, perhaps I'm being a grumpy old man late in the workday, I'll leave it be :-)
Having seen in enterprise incredible amount of man-hours wasted on migrating, re-writing and creating POCs on the latest fad, I sometimes wonder whether this cycle is productive or we keep at it just to keep our brains working and not go insane thinking of geo-political/financial/meta-physical questions. Its perhaps Crack for the tech crowd.
Earlier quoted context omitted.
Devs are people. Getting people to use things requires communicating to them what the things is for, and how it is better than other alternatives, and how to use it to realize that benefit. Therefore, devtool adoption requires messaging related to what the devtool is for, how the devtool is superior to other alternatives in the same space, and how to use the devtool to realize that superiority. Actually having the to…
I get that you want to make people aware of the tool and its advantages because you think others might find it useful. But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it. Anyway, perhaps I'm being a grumpy old man late in the workday, I'll leave it be :-)
"messaging" isn't a condescending idea, its simply having clear, coherent means of communicating some message, with awareness of the audience that message is directed to. Like, what your product is for and why people should (and how they can) use it.
http://www.markroseman.com/tcl/dyingout.html (ref: https://news.ycombinator.com/item?id=9689046)
Edit: link to submitted story.
Earlier quoted context omitted.
From that article: "The Architecture Astronauts will say things like: "Can you imagine a program like Napster where you can download anything, not just songs?" hahahahahhaha bittorrent.
Even Napster was used for non-music stuff towards the end, by renaming archives as mp3. And the basic protocol was later adopted for more generic sharing systems, never mind the number of clones that came about after Napster was lawyer bombed. Bittorrent is just the latest in a long string of P2P systems, with the biggest difference being the lack of a central search server.
Well these technologies are there to help bring Google type infrastructure for businesses that need it. If you're running a CRUD app just fine on Heroku you don't need to do any of this and you shouldn't. When your availability starts having problems or your data is getting too much for one machine, you start having problems of scale. Where you are in terms of scaling issues should lead you to the next iteration of t…
Because I don't think anybody else wants to risk angering the hivemind: I'll just say it--pretty much only Amazon, Google, Facebook, Apple, Baidu, and perhaps a small handful of other companies need Google infrastructure. Everybody else is probably just chasing shiny on their investors' dime.
This hits home. While everyone is talking containers, we're running simple processes with a Linux user per instance, and I feel no need to add more complexity to our system, except I'm really struggling to automate stuff. It seems that if you aren't running a full dockerized cluster of services or outsourcing everything to a PaaS, you're left with building all the infrastructure yourself. What did people use before t…
I think there is a mix of things being bandied about under the "container" banner. On the one hand it is about getting more bang for your hardware buck. On the other it is about someone getting so deep into netsec that they have developed gills. In the bang for bucks category you have a chain of one box pr database etc. Then noticing that the hardware sits idle most of the time, so virtualization is depolyed to pack…
This hits home. While everyone is talking containers, we're running simple processes with a Linux user per instance, and I feel no need to add more complexity to our system, except I'm really struggling to automate stuff. It seems that if you aren't running a full dockerized cluster of services or outsourcing everything to a PaaS, you're left with building all the infrastructure yourself. What did people use before t…
A couple of decades of experience is encoded in CFEngine: http://en.wikipedia.org/wiki/CFEngine http://cfengine.com/product/community/
I wonder what's the architecture behind WPEngine and similar services. It must provide some isolation since clients can install their own plugins, but on the other hand I don't see them creating a new Docker image for each client, especially since they're self-managed.