8 ms·
> I'm an application developer and I do not want to become a release engineer. I resent even having to learn Docker. :-) Sorry, but that's a terrible attitude
by bogwog 4y ago
> I'm an application developer and I do not want to become a release engineer. I resent even having to learn Docker. :-)
Sorry, but that's a terrible attitude to have. You don't need to be a full-blown sysadmin to know how to do basic deployments, and learning these things will make you a better developer.
- guggle 4y agoI don't know why this is downvoted, it's probably the best advice on this page. Learning a few things about deployment definitely helps to make better software.
- ilyt 4y agoThat often quickly leads to "chmod -R 777 makes the app work and I don't give a shit about doing it properly" if your passion is dev, not ops
- irskep 4y agoWell, he did cherry-pick one joking comment out of a well-intentioned post in order to say I have a bad attitude, so that's not exactly welcoming. And very patronizing, considering I have actually done that kind of work with Salt Stack a few years ago, and just don't want to bother with it at the moment because I have other priorities. I learn new things every day, and one day, Docker was that thing. I am now better at release engineering, cool! But I also lost a day of working on shipping value to users and actually having fun, which is less cool. That's why PaaS has been helpful to certain kinds of people; it makes the curve of progressive disclosure necessary to deploy stuff a little flatter. My hope is that we can make more kinds of things really easy to do the right way, and not yell at people who just want to have some fun.
- guggle 4y agoSure, that comment came a bit rough. But I'm not even sure it was triggered by the Docker comment, rather than the developer/release engineer opposition. At least that's how I see it. And maybe I just don't see the added value of PaaS because I've been spinning up public web servers for too long now ;-)
- irskep 4y agoYeah, that's fair, and it was bad phrasing on my part. The engineer type distinctions are completely imaginary. It just really threw me off to have people respond to me sharing something I thought was helpful with claims that I'm somehow opposed to learning, when this project is nothing but learning. I do think people who have experience deploying software have a blind spot here, just like I have a blind spot for people who have never learned how to center a div. jUsT uSe FlExBoX
- ZahiF 4y agoHey there, I've never deployed anything but will be going to in the (very) near future. I'm self-taught and really haven't fooled around with servers, ever. So instead of just going down the PaaS way I was hoping to kind of turn my computer/raspberry pie into a server as a fun learning project. Any cool, beginner friendly resources you can share? Many thanks
- cutler 4y agoAgreed. Too much reliance on AWS, Heroku etc. can leave you without vital Linux skills. Linux cli tools are not just for getting a job done, though they're great at what they do. No, they're part of the *nix culture which is what open source software is based on. Only recently have I become aware that it was better to have entered software development in or before the early 2000s, ie. before The Cloud took off. You were forced to learn Linux/BSD cli tools just to swim in the water. I can't imagine, back then, knowing Perl and not knowing Linux or FreeBSD.
- bravura 4y agoI used slackware linux. I wrote assembly code when I was a teenager. I use 'perl -i -pe' constantly. I still don't want to learn a bunch of arcane flags from a bunch of tools with a million gotchas. Sorry. I'd rather focus on the code craft that gives me joy these days. Sorry, I detest this attitude of: "Well I was hazed so why aren't you hazed too?" Did I mention that Russ Cox and I used to write C code with pen and paper? https://news.ycombinator.com/item?id=32874759 https://news.ycombinator.com/item?id=32874759 If you haven't, are you even qualified to discuss what vital skills others are missing? Or maybe because I learned perl because it was simpler than tr and awk, I should STFU? Give me a break.
- orthecreedence 4y ago> I used slackware linux. I wrote assembly code when I was a teenager. Lol are you me? I grew up with Slack/assembler/softice/etc and I used to host everything on Slack boxes on Linode (bless them for having a pre-built image). But I left it a while ago because I got sick of dealing with hand upgrades and compiling everything from scratch. I feel the same way about other things. I could probably out-CLI most of the people here saying "you should learn linux!" but sometimes I just need to get something done. If I'm trying to get something out the door, I don't give a rat's ass about the details. It's fun and interesting when you're a teenager and it's 4am on a summer night and you've got nothing better to do, but these days I have strict time, limited energy, and I'm not going to spend more time fiddling with things than I need to.
- ilyt 4y ago
- VyseofArcadia 4y ago>learning these things will make you a better developer. Of webapps. Will make you a better developer of webapps. It may surprise you to learn that there are more kinds of software than that. Sometimes the final product is something like a binary that runs outside the browser, and deployment is no more complex that putting an tar.gz'd executable on a website.
- lolinder 4y agoThis whole conversation is about using SQLite on web servers, so I think it's reasonable for OP to assume that's what we're talking about.
- anyfoo 4y agoI'm not sure what that has to do with sqlite. I'm very much a non-web-developer, I never use Docker and "deployments" and stuff, but sqlite is absolutely trivial to install and run, and use for non-webapp stuff? Even operating system components use it.
- VyseofArcadia 4y agoThat's my point. Everyone is assuming web app.
- JohnBooty 4y agoYou don't need to be a full-blown sysadmin to know how to do basic deployments, and learning these things will make you a better developer. Yes. True. However, it is also true that we have a limited amount of time per week and a limited number of weeks on Earth. Time spent learning sysadmin-y stuff is less time spent mastering developer-y stuff. Think about what it means to be a "full stack" engineer in 2023: - Unix literacy including common tools (awk, sed, grep, etc) - Docker, etc. - Relational data stores - Key/value and document stores - Base frontend technologies (HTML, CSS) - Frontend frameworks and the associated language - Build pipelines to tie it all together I've never worked with anybody who's deeply knowledgeable at all of them, or even most of them. I would submit that it is practically impossible to master all of them while also holding a full-time job and writing and shipping production code, and staying "current" on all of the above, unless you're willing to go way past 40-hour weeks. I've grown extremely disenchanted with "modern" software development. Your typical full stack engineer is frankly bad at most of the damn stack and they're not great at any of it. Nobody masters anything anymore. You get people with IQs three standard deviations above normal thinking they need to spin up an armada of AWS crap just to render "Hello World" in 2023. And they still manage to make a mess of it. I can't tell how much of this is brain damage and how much of it is a sociopathic commitment to resume-driven development. In practicality, I'm a fan of "T-shaped" engineers. Master a piece or two of the stack, and have light knowledge of the adjacent layers and what they do. e.g. If you are an application-level coder you should know what Docket/K8s/etc are and when/why you might use it and when you should eschew them. And honestly I think it should be eschewed fairly often. The places you can go with a bit of good old vertical scaling are pretty impressive in 2023. A single box with e.g. 24 cores, 64GB of RAM, and fast solid-state storage is a god damn supercomputer when it comes to spitting out web pages. Think about how far Stack Overflow got with that model and at which point you might start to outgrow them. --- edit: By "mastery" I mean "fairly comprehensive competency" and not "be a recognized global authority." You can fluently use 50-75% of what the tool offers and you know what the other 25%-50% is so you can learn it and utilize it when needed. You can ship code using this tool that is maintainable and performant. For example, perhaps you've never utilized partitioning in Postgres but you know what it is and you understand the appropriate use case for it so you can learn employ it when needed.
- 4y ago
- deleted 4y ago[deleted]
- thelittleone 4y agoOne consideration for small vendors who target mid-market or larger customer segments is Vendor Risk Management assessments. These typically dive into resilience (among other things) along with roles and responsibilities. If it's running on a PaaS a good chunk of responsibility can be delegated under the shared responsibility model.
- justinclift 4y agoAt the same time, I kind of wonder at the direction of things when pretty much every package and application has decided to embrace becoming more complex over time. It's only going to increase cognitive load, potentially without end (?) which doesn't sound wise long term. :(
- jmplng 4y agoCan’t even make 1 joke without attracting the ire of the supersmarts.
- michaelteter 4y agoSo many things (deployment and productionizing) are easily possible without Docker, so why add that layer of complexity unless you know you have a good reason? Why make Docker and essential part of a system before you actually need it? There’s a reasonable chance that you never need it. I know this, because a lot of business and hobby systems have been in operation since before Docker existed. Docker has value in many cases, but it certainly doesn’t have to be a necessity.
- ilyt 4y agoentirely depends what you're deploying. Go app which is one blob and some static file ? Sure. Java app that just needs JVM in system ? Go ahead, .service systemd file with some limits is all you need. Ruby on Rails ? Put that radioactive shit in container, else your server will need to have a bunch of -dev packages just to compile gems and make it running (or alternatively you'd have to compile the gems on same environment server is running, which is more work than just making a container)
- michaelteter 4y ago> Ruby on Rails I've been deploying Rails since v 2, and never with Docker. The only time I ever had trouble was setting up Rails dev on M1 Mac when M1 was new. In Linux production, it just worked; and pulling/building gems was less a drag than what people regularly experience in the NPM world. To be fair, I don't use a ton of gems because I generally don't like additional dependencies unless the value is really there. So maybe my use cases have been too basic to experience the pain.
- ilyt 4y agoI mean, it isn't a big deal, just few packages need to be installed, just compared to "put a blob on server, run" it's more complex. It's all fine if you use any kind of configuration management as it is just write once in manifest and done. But if you just install it directly via package manager, leave alone and need to say reinstall server or something, the knowledge is lost. I remember having a lot of ping-pong between ruby devs where they, well, didn't note down what system libs and dev package they needed, just had them installed locally at some point and forgot about, then surprise when app isn't compiling on server.
- orange_fritter 4y agoMost of us are perfectly capable of learning new technologies, and there is no shortage of software and disciplines begging for our attention and adoption. For me it's not a matter of "can I learn this" but "do I want to spend my most limited resource--time-- pouring through docs and tutorials to become a few levels below competent at x, y, z, etc, etc, etc interesting systems." Some systems are intrinsically rewarding because they yield thinking tools that can be applied to other systems, while others, like Docker, are pretty much never fun and just a tool.
- tdubhro1 4y agoIf you’re actually busy then everything you say yes to necessarily means saying no to something else. If I start a hobby project to learn about and play with technology X, and I end up yak-shaving technology Y, I’m wasting my time and not achieving my goal.
- ilyt 4y agoHere is the caveat - you have to learn and be interested with it. If you just want to do the minimum to run the app, it will make you worse and usually utterly terrible sysadmin, as it usually is going to be "do the minimum required amount of copy-pasting from tutorials to make the stuff running". Then inevitably don't update shit, nor even set unattended-upgrades package. And if the server won't get hacked from bad firewall and no updates, the server will ran out of space because dev of course didn't thought about data management and some log file in wrong place without rotation overflowed. That's from decade+ of fixing shit of developers that think that tutorial on internet made them sysadmin.