51–60 of 146 posts
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 this great new wave?
Earlier quoted context omitted.
Can we make it cheaper than we can buy it? Is their purchase price more expensive than my hourly wage for a few months?
Can you guarantee success at development? And even if you can, is it a good idea? The coolest software project I've ever been on was also the dumbest. We were trying to build a bios in-house - something that can be bought off-the-shelf for a buck. In theory, it could have saved us millions in the long run. In the short run, we were wasting man-months of engineering on something that was not our business, when the clo…
Blame the employees for crappy management. Sounds like fun!
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…
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.
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 to read and easy to write.
On Docker's website, there's a huge amount of confusion about what Docker even is. A platform? A runtime? Both? Which is the one I should care about?
The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy. It's that attitude towards UX that has lead to the following one-liner to being the only way to do something so mundane as "removing all your untagged images":
docker rmi $(docker images | grep "^" | awk "{print $3}")
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…
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.
Outsorcing became a Wall Street fad once a few big name companies did the numbers and found they could reduce costs by doing so.
Soon "everyone" was doing it, or announcing that they were going to, even though they had little to nothing to gain from it.
As that saying goes: when all you have is a hammer, every problem looks like a nail.
And right now that hammer, at least in terms of IT, seems to be containers.
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…
Ughhh this. I just want to give my project to a PaaS and let them figure out everything. I was looking into Google App Engine, but they didn't support some language features I wanted (e.g. Java 1.8, Servlet 3.X["I know, programming in Java? You're stuck in the past"]). So I looked into their new Container Engine. But like this article points out, it makes deployment 500000000 times more complicated than it should be.
https://run.pivotal.io/features/
?
Java 1.8 and Tomcat 8.0.x, so Servlet 3.1. On a good day, deployment is one command which just does its thing.
It's not without its quirks, but in my experience they're fairly minor.
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…
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.
Earlier quoted context omitted.
Can you guarantee success at development? And even if you can, is it a good idea? The coolest software project I've ever been on was also the dumbest. We were trying to build a bios in-house - something that can be bought off-the-shelf for a buck. In theory, it could have saved us millions in the long run. In the short run, we were wasting man-months of engineering on something that was not our business, when the clo…
>I'd at least threaten to fire them if they even thought about it again. Blame the employees for crappy management. Sounds like fun!
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.
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…
docker rmi -f $(docker images | grep "^" | awk "{print \$3}")