:P I still write orchestral music with Cubase on a 1999 IBM PC running Windows ME. Writing this comment on my new (2005) computer with OmniWeb browser, os x 10.4. Hmm maybe I should be in healthcare.
We mostly use docker with docker swarm. Currently exploring moving to Rancher. Also we use Gitlab CI for CI/CD. Our workflow looks like this: a release is tagged, CI tests and builds a docker image which is pushed to our private registry and then we use ansible to deploy the new release on our servers. We mostly use onprem for our production and can't use any cloud with the regulations and limitations we have.
We [1] use a Laravel back-end for the main system, hosted on autoscaling EC2 behind a load balancer.
Our front-end web application is built on Angular, running on S3 behind CloudFront.
Since we process a lot of data, we use background jobs (with SQS as a broker) to perform our analyses.
The actual data processing and wrangling is done in Python.
We have released some parts of our systems as open source projects [2], [3], [4].
I agree! Lumen is my go-to framework for small web-based things right now, picking things from Laravel is so powerful.
1) At the time, Python (and with it pandas/numpy) seemed to be a good fit for the data we were working with (and the analysis was developed as a separate project from the main system that calls it). If we were to do it over right now (and we well might in the coming months) we would probably move this into PHP as well, which makes writing workers much easier.
2) Cost-wise, SQS makes a lot of sense - the system is highly distributed and cut up into parts (the description in my first comment is a bit simplified) so adding redis to the mix means adding a whole new server. For SQS, we're just paying per-message (and we don't have a _lot_ of messages, so it's cheap).
Furthermore, I've built an algorithm to scale up the background workers based on the queue size of SQS. This runs in Lambda, which makes it super easy to access SQS properties versus connecting to a remote redis server. Basically, the algorithm rents new EC2 instances whenever the load is high and terminates them whenever the load is low.
I guess so. It seems strange to me that anyone would want to inflict upon themselves the pain of using different environments for development vs. production, though.
You'd think so, but I bet a large portion of developers on hacker news develop on a mac and run their apps in production on a linux distro. At least for web apps.
Could be. I know a lot of Mac owners who only ever do three things directly in OS X though: Run a web browser, use video conferencing software, and launch linux and BSD virtual machines.
Just deployed a lambda script that spins up a FreeBSD ec2 image that checks out, compiles, and runs the contents of a dynamically provided git url, with dynamically specified pkg and pip dependencies to make my own long-running FreeBSD-based lambda-esque service for some continuous deployment.
Wouldn’t have been possible without the ec2 images and the configinit magic.
Plain Ruby + Sinatra+ Puma + MySQL (ConnectionPool) + Sidekiq on Redis for the back-end. Sinatra/ERB for low-traffic sites, and ReactJS on S3 for more traffic on the front-end. I always like to err on the side of common denominator, rather than adding as many 'currently hip' tools as possible. Every time I try new things, it eventually brings me back to this set of tools.
Haskell & Elm. Deployed to AWS with NixOps. Persisted with PosgreSQL and Redis. Code hosted in either Bitbucket or GitHbub. Tasks managed with Trello and email. Occasional sync meetings over appear.in or Zoom (I travel).
NixOps supposedly supports several hosting providers, but the DigitalOcean integration is currently broken. AWS works great, but it's annoying to be forced into that choice by the tool.
Haskell and Elm both work great, but I can imagine in future using something like Haste or PureScript Bridge; it'd be nice to work with both the backend and UI as a single project. Not a pain currently, but this is a nice to have.
Biggest pain is documentation. Haskell stuff is documented, but more hand-holdy examples would be ideal. OTOH, some language communities have a culture of writing documentation that is too hand-holdy, flooded with emojis, and is generally frustratingly infantilising. I'd like Haskell to strike a balance between the two. I'm optimistic we'll get there eventually.
Nope. Not in any of the several products I've put in production with Elm. There have been times when I've needed more things than Elm provides — one time I needed a library for parsing a streaming JSON response — but the JS interop through ports works just fine.
Seconded. I use it with the go-bindata backend and Postgres driver. Some notes:
- Migrations are written in plain SQL, so there may be portability issues if you need to support multiple DBs. (Or you need to write the same migration once per supported SQL dialect.)
As an indie founder, I prefer to use Node/Express and React/Redux, hosted on Digital Ocean. Really fast and convenient to build SaaSes and single page apps like:
127 comments
[ 1.7 ms ] story [ 228 ms ] threadwe also do java applets
Definitely the best stack I have worked with thus far.
We have released some parts of our systems as open source projects [2], [3], [4].
[1]: https://odysseyattribution.co/ [2]: https://github.com/code-orange/telemachy [3]: https://github.com/code-orange/jot [3]: https://github.com/code-orange/statuspage
A couple of questions:
1. Why did you go with Python for data processing instead of PHP?
2. Why not use Redis for queue/background jobs processing?
1) At the time, Python (and with it pandas/numpy) seemed to be a good fit for the data we were working with (and the analysis was developed as a separate project from the main system that calls it). If we were to do it over right now (and we well might in the coming months) we would probably move this into PHP as well, which makes writing workers much easier.
2) Cost-wise, SQS makes a lot of sense - the system is highly distributed and cut up into parts (the description in my first comment is a bit simplified) so adding redis to the mix means adding a whole new server. For SQS, we're just paying per-message (and we don't have a _lot_ of messages, so it's cheap). Furthermore, I've built an algorithm to scale up the background workers based on the queue size of SQS. This runs in Lambda, which makes it super easy to access SQS properties versus connecting to a remote redis server. Basically, the algorithm rents new EC2 instances whenever the load is high and terminates them whenever the load is low.
Yes, the dynamic parts of the Tarsnap website are written in C.
Just deployed a lambda script that spins up a FreeBSD ec2 image that checks out, compiles, and runs the contents of a dynamically provided git url, with dynamically specified pkg and pip dependencies to make my own long-running FreeBSD-based lambda-esque service for some continuous deployment.
Wouldn’t have been possible without the ec2 images and the configinit magic.
-mqudsi@neosmart
tldr cperciva is a long time BSD guy...
Nothing special, but it gets the job done.
Amazon S3 for storage, db/redis for queue processing.
Great setup, a lot of the headache is taken out and lets us focus on the development aspects of creating software.
Haskell and Elm both work great, but I can imagine in future using something like Haste or PureScript Bridge; it'd be nice to work with both the backend and UI as a single project. Not a pain currently, but this is a nice to have.
Biggest pain is documentation. Haskell stuff is documented, but more hand-holdy examples would be ideal. OTOH, some language communities have a culture of writing documentation that is too hand-holdy, flooded with emojis, and is generally frustratingly infantilising. I'd like Haskell to strike a balance between the two. I'm optimistic we'll get there eventually.
https://fibery.io - Work management platform for SMB
Stack:
Clojure
PostgreSQL
Kafka
React
Javascript
Frontend - React app
DB: MySQL
- Migrations are written in plain SQL, so there may be portability issues if you need to support multiple DBs. (Or you need to write the same migration once per supported SQL dialect.)
- It does not `CREATE DATABASE` for you when applying the first migration. For my app that uses Postgres, I wrote some extra code to do that. Feel free to copy if you like: https://github.com/sapcc/limes/blob/ab4245a8f195672b808f990f...
For migrations we use goose: https://github.com/pressly/goose
https://nulis.io
https://helix.startuplab.io
If I don't need a lot of fancy interactive functionality, and am building more of a usual web 2.0 website, I sometimes go with Django/PostgreSQL:
https://fictionhub.io
http://webacademy.io
http://lumiverse.io
For static blogs and content websites, I go with pelican generated sites simply served with nginx:
https://startuplab.io/blog
I'm curious if you prefer Django over js alternatives for any particular reason?
- dojo
- IE11
- jenkins
- we are not a startup :)