131–140 of 146 posts
Earlier quoted context omitted.
And then that data center has a fire, your server is gone, your data is gone, your business loses X thousands of dollars per day, all because everything was on one server.
I usually have backups to a cloud, so thats's really not a problem.
It really is striking how products like Docker, even while delivering incredible value, continuously fail to message themselves in an intelligible way. If you go to https://www.docker.com , you see: "Build, Ship and Run. Any App, Anywhere." Jesus Christ. I get that you're The Future, but make the value prop for me here, at least. Why should I use Docker? What parts of my stack does it replace? When does the cost-bene…
Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common…
Whether this is good front-page marketing is above my pay grade, of course ... it may well not be.
Earlier quoted context omitted.
Seems to be the problem with a lot of technologies. If you're a HN reader, you can start to get the feeling that you're falling behind if you're not doing these things. Even though they are totally inappropriate for the majority of us who are working on smaller systems.
As an engineer I feel an obligation to know about these things and how they work. It might be appropriate for my work. For my own projects I am just going to start out with a Django or Meteor app and if I'm lucky enough to have to worry about scale I'll have some idea of what to do next.
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.
Earlier quoted context omitted.
I find that position to be very hard to understand - devtools live or die by their adoption. A clear understanding of what a tool does is critical to its adoption. Look at, say, the homepage of Ruby: https://www.ruby-lang.org/en/ . There's a clear, two sentence explanation of what it is: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural t…
"I find that position to be very hard to understand - devtools live or die by their adoption" Some of the time, that is true, but not all the time, maybe not most of the time -- you are putting the cart before the horse. In fact, I would argue that this is an anti-pattern. Yes, you might use (e.g. to pick 2 unrelated domains) Hadoop or Python because they are popular, but consider how they got popular in the first pl…
That sounds rational and it's what I used to think, but I think this talk (https://www.youtube.com/watch?v=FzzL_QDKv0c) makes a good case that fuzzy human factors always play a role in technical decisions, and that's not necessarily bad.
Eg, which is better, Angular or Ember? Ruby or Python? Go or C++? Haskell or Common Lisp? You can accomplish the same things in either tool. Which you like better has a lot to do with what you already know. And popularity may seem like a shallow measure, but it affects whether you can get questions answered, find blog posts and books, locate a library to do something for you, and hire developers who already know the technology.
Popularity is probably also weakly correlated with stability. If my custom jQuery code doesn't work, there's a 99.999% chance that it's the fault of the code I wrote (used by 1 person) rather than of jQuery (used by thousands). When jQuery was new and used by tens of people, there was a higher chance that it was jQuery's fault.
Earlier quoted context omitted.
As an engineer I feel an obligation to know about these things and how they work. It might be appropriate for my work. For my own projects I am just going to start out with a Django or Meteor app and if I'm lucky enough to have to worry about scale I'll have some idea of what to do next.
> It might be appropriate for my work. so might be AS400, but few are trying to learn that I guess. Let's be fair, it's quite likely that if anyone is looking into this stuff is more because it's the technology du jour, rather then the off chance that they end up with 100 million users. It could be useful, and learning stuff is fun, but that's not the real drive.
Knowing the technology du jour is a lot more likely to get you a job, even if an older technology is better in some ways.
Earlier quoted context omitted.
Thanks for the frank feedback. I agree that we have a lot of "wiggle room", as you so diplomatically put it. Out of curiosity how do you feel about the current README on Docker's repo? https://github.com/docker/docker/blob/master/README.md One problem we've encountered is that the audience for Docker is incredible broad - much broader than you might imagine when reading Hacker News for example. It is extremely common…
I read over and over about docker, did some tutorials. But when my boss asked me: should we use it? And can you please explain one more time what is it anyway? I simply say, well, it IS like a VM but without the VM. No other explanation stuck for me, and I'm sure it's a wrong description of what is docket, but the messaging so far got at least this part for me as the quintessential "what's that docker thing again?" I…
I have trouble with the idea of calling them 'the future'. So far, I haven't seen a REAL reason to use docker in a production environment.
Earlier quoted context omitted.
>I'd at least threaten to fire them if they even thought about it again. Blame the employees for crappy management. Sounds like fun!
It's not crappy management for engineers to have technically cool ideas that are bad business, and then rationalize their value. It's bad management to let them execute on them (except if you have some sort of do-what-you-want time for developers, which is a good way to compensate and balance for this).
These kinds of managers are utterly toxic. At the slightest hint of this kind of behavior, I'd be reaching out to my contacts to find new employment, where I would certainly be paid better, but hopefully don't have a feudal work environment.