461–470 of 569 posts
The only downside I saw was learning a bit of cloud formation to automatize the stack creation. But I guess if you want a quick prototype/deploy you might as well do it manually and learn it later.
I really recommend you to take a look at AWS's serverless products: https://aws.amazon.com/serverless/
Earlier quoted context omitted.
And plus, it works on cheap shared websites that can cost $10 a year + domain name.
Isn't the "PHP works on cheap hosting" schtick a bit dated now you can get a dual-cpu VPS with 8GB RAM at hetzner.com for 8.90 Euros per month? Commodity hosting now makes JVM apps feasible at the lowest price points.
If you need to build an API quickly we just launched https://code.xyz on Thursday. No server provisioning, no routing, nada, just write a JavaScript function, hit deploy, and you have a scalable "serverless" backend. You can deliver any type of content. (We have command line tools available as well, if the web environment doesn't suit all your needs.) Our company is called StdLib, we're focused on making API developm…
That's pretty cool! Literally took me 10 seconds to sign up and deploy the sample function.
It tends to depend on what I'm setting up but these days I've shifted from Heroku onto services like now.sh and Netlify (not to discount Heroku as a viable option here) when I just need to get something online, quick and dirty. There's less commitment which is ideal because you're not going to know the full requirements for your app until you've begun to flesh it out more, so you can buy yourself some time to figure…
I don't know how you guys did it 10 years ago, I couldn't even last 2 weeks with that system
Earlier quoted context omitted.
Can you give me a resource to get started with devops. I have only heard these ideas, but don't have any clue why at all they are required.
The idea is to automate repetitive tasks as much as you can because doing them by hand takes time and is error-prone. Build, deployment and testing are tasks that are well suited to automation.
I started by automating things that would take too long. At first it was taking code from my repository and deploying it to Heroku. Then I discovered that CI services literally gave you servers to run scripts on to interact with your code after a git push, so I started running tests in these servers.
Fast forward a few years and I automated everything except writing and maintaining the codebase.
I even run linting tests in CI so no badly written code can even make it to code review.
Earlier quoted context omitted.
The benefit of Golang isn't that it's compiled. It's that it has a good IO and concurrency model and the language is strict enough to force certain good practices on developers. IMO it would be almost as good even if the code execution were as slow as Python or Ruby.
I hear this a lot about Go, but doesn't the webserver handle concurrency for you in most cases? I don't do a whole lot of explicit threading work when I write webservers in Java for example. Or is there something I'm missing that you use the Go primitives for in these cases?
There are Tornado and asyncio libraries for Python that give you asynchronous networking. But you have to totally rework how you write Python code within those request handlers to factor out blocking IO which makes using existing libraries for DB and such a pain.
Go is built from the ground up to handle IO like that asynchronously so all of your libraries and stuff will just work in that context.
NodeJS is similar to Go in that regard, but the JS language has baggage that gives you weird blends of callback asynchronicity mixed with async/await and it generally just doesn't feel as nature as Go.
Sometimes a simple request/response model isn't enough. Maybe you need a streamed (chunked encoding) API or WebSockets where the performance for massive numbers of connections using threaded servers is going to tank quickly compared to a language like Go that handles the IO and concurrency better from the ground up.
Earlier quoted context omitted.
Isn't the "PHP works on cheap hosting" schtick a bit dated now you can get a dual-cpu VPS with 8GB RAM at hetzner.com for 8.90 Euros per month? Commodity hosting now makes JVM apps feasible at the lowest price points.
8.90 EUR per month is about $130 a year, so still an order of magnitude more expensive than cheap PHP hosting.
I write the server-side in Go, cross-compile to a Linux binary, and set that up as a service on a vanilla Ubuntu box (usually Digital Ocean). Deploying a new version is a matter of sftp'ing the new binary (and any templates, images, etc) over the top of the old one and restarting the service. If I need a database then I use Postgres, and the setup for that can be a pain, so I get it documented/scripted using Ansible.…
Your description would seem good for something management etc has down on paper / a design document.
Earlier quoted context omitted.
I keep on running into this problem where I try to use a new framework/language for backend, like Go, Kotlin, even Node, but I just get so damn bored with writing the same boilerplate. Say what you will about Rails, but at least the maintainers try to automate the boring parts. Not to mention between Elastic Beanstalk, Heroku and even plain old Capistrano on a VPS, deploying Rails is a breeze. Maybe some people take…
I’m curious: once one has written a CRUD app, why can’t they use that as the boilerplate for other CRUDs they need to write? Replace the bits specific to each individual app. If the program is designed in a sufficiently modular fashion, shouldn’t this be doable?
For some reason people seem to constant doubt Ruby-ists and Rails Devs. I completely get that other languages have huge benefits over Ruby. Golang being compiled or Java running anywhere, etc... And ruby is slow, totally understood. But if youre talking about getting a functioning webapp up and running quickly ... no way anyone is beating a Rails dev in setting one up. The piping and scaffolding are all built in and…
I usually rip a bunch of stuff out of their default app template and actually get the app doing something useful first before I deploy but it's really easy.