I didn't think it'd be so interesting as to publish it separately, thanks! It's built on top of my own Picnic CSS (in above comment) but with many px/em/cm-specific adjustments as seen in https://francisco.io/resume/cv.css
For those who understand networking: the Mirage TCP/IP networking
stack [1] in pure OCaml is a must. It's an object of extreme beauty, and
possibly the most eloquent argument for types, types inference and
algebraic data types I can think of. The TCP state machine is mostly specified at type level [2], preventing numerous potential bugs in one fell swoop.
Reading this code is probably most enlightening if you have already written networking protocols.
NB: this has nothing to do with OCaml, other comparable languages with ADTs (Scala, Rust, Haskell, F#) would be similarly suitable.
They've put together a very comprehensive list of places to post your startup, and some will certainly be relevant to just side projects etc. Depending on what you're looking to showcase.
This will certainly be one source I'll look to, for what I launch my side project.
A lot of the don'ts are kind of domain specific (and the rest are kind of "don't do the opposite of the "do" column), and the majority of the "dos" are the kind of thing you always hear everyone saying, but once you've felt the pain it really drives the point home:
* Have a testing framework in place (you don't need 100% of tests written during dev, but make sure your shit is testable and written with tests in mind)
* have a deploy plan that is one step
* have a rollback plan that is one step
* have backups running way before launch
* have one-step restores from backup running before launch
* make sure your restores make their own backup before running (yeah... that day sucked)
* write enough documentation that someone not involved in your project can setup a dev environment and make simple changes/deploys/rollbacks
* document your production system setup and make sure you can reproduce a production system from your documentation alone (this WILL bite you in the worst possible time if you need it!)
* make sure you have a plan for database migrations and it works 100% of the time (and in both directions! Have a "deploy" migration as well as a "rollback" migration for every single change!)
* Have someone that is not a developer use the app without any documentation (this is huge)
* Have a lot of logging and a way of easily viewing them (you can always turn logging down fairly easily, but adding it after the fact is a lot more work)
* build a lot of "support help" tools in from the start (things like the ability to see errors that happened from a specific user, or at a specific time, or in enterprise applications the ability to grab screenshots from the device that is being helped, or built-in remote desktop if applicable)
* Get a bug reporting system in place so users can easily send you problems and issues with as much information as they are comfortable with
* make sure you can deploy hotfixes easily and at any time even if the live version of your app is months behind master
* plan to have more developers at some point. Even if you don't now, even if you can't fathom having more than a few people, just keep it in the back of your head that there's a chance that 10+ people could be working on this code, so maybe that cute one-liner shouldn't be used here...
* stick to a style guide
* put a version number somewhere visible in your app (even if it's REALLY small) so when people send you screenshots you can instantly tell if they are behind or up-to-date or if they got yesterday's hotfix, etc...
Feel free to reuse any of the code under the MIT.