whatever brings you happiness.
I spend little on experiences like vacations and tend to enjoy the experience leading to a purchase and usage of a thing. E.g. researching what guitar effect pedals would be cool is as enjoyable to me as using it to create sounds after I buy it. This also has an interesting side effect that often I'm satisfied without actually acquiring a thing but when I do - it leads to a better quality (whatever that means in that particular case) but also more expensive thing
I'm not going to claim this necessarily applies to you, but there's some research that suggests spending money on experiences rather than possessions tends to result in longer term happiness. See for example:
Our team uses them extensively. It's also tied to our A/B and QA testing infrastructure as it performs a similar function of "turn this/that on/off for these particular users". This enables us to do continuous deployment (dead/unfinished code goes to live all the time) and running QA for features on live infrastructure that has actual production loads.
It's also a life saver when issues arise, though the correct term for this is "operational toggles". Flip a switch when functionality is causing issues and it's gone.
Eneba | Kaunas, Lithuania | Full Time | Onsite (remote while quarantine is in effect) | Backend, frontend developer | https://www.eneba.com/
Eneba.com is a newly established marketplace for games. With a huge selection of titles at the best price, Eneba is quickly becoming a go-to place to find the best game deals. While game collection in the market grows by the day everyone can find something for their liking - fresh new games, world-renowned game titles or various console giftcards.
Our merchants rave about us and we're steadily growing a loyal client base.
We had one the biggest seed rounds in the Baltics and we're in the gaming market that actually grows in recessions/quarantines.
We have a very strong team (tech and business wise) and are looking for people that are willing to join and learn.
We're looking for
* mid level backend developer. You'd be working with php (symfony) most of the time, a bit of golang and occasional devops tool.
* junior/mid level frontend developer. You'd be working with react and apollo
Hiring: we do a <1h meet to get to know each other (video conf. due to quarantine) and ask to spend a few hours on a coding task at home.
Eneba | Software Engineer | Onsite Kaunas, Lithuania | Full Time | https://www.eneba.com
Eneba is a games marketplace. We're a startup that had one the biggest early investment rounds in Lithuania. The whole team operates in the same office - support, marketing, it, sales and so on.
We're looking for php and frontend devs of mid/senior level.
We have an onsite interview (~1h) to get to know one another. If we're still interested after that - we ask to spend a few hours with a coding exercise at home or show us some public code you've written.
Backend tech you'd be working with: php, symfony, graphql, elastic search, kubernetes, terraform
Frontend: react, apollo, graphql
Write to jobs at eneba.com or karolis at eneba.com, mention you found this on HN
Nowadays - flip a toggle in the admin. Deployments and releases are separated.
Made a major blunder? In kubernetes world we do "helm rollback". Takes seconds. This allows for a super fast pipeline and a team of 6 devs pushes out like 50 deployments a day.
Pre-kubernetes it would be AWS pipeline that would startup servers with old commits. We'd catch most of the stuff in blue/green phase, though. Same team, maybe 10 deployments a day but I think this was still pretty good for a monolith.
Pre-aws we used deployment tools like capistrano. Most of the tools in this category have multiple releases on the servers and a symlink to the live one. If you make mistake - run a command to delete the symlink, ln -s old release, restart web server. Even though this is the fastest rollback of the bunch the ecosystem was still young and we'd do 0-2 releases a day.
Why not canary releases? You can load balance for example 1% of the traffic to the new deployment and see if you experience any issues. If you do - you just change the loadbalancer to use the known good pods.
Honestly, we haven't considered that.
Breakage rarely reaches production, rollbacks are quick, a process orchestrator retries most of the stuff and because of that we do not have a problem worth solving with "canary deployments". Note that we do sometimes carry out "canary releases" via toggles.
This depends a lot on the databases used and flexibility of the code that's accessing the data.
One method is to deploy in multiple stages and to use views. In pre-deploy you create a view with schema/data needed for the release. In deploy stage you roll-out the canary code. In post-deploy stage remove either the old data/schema on success or new data/schema on failure.
It's quite an overhead to implement and maintain this process.
Uploading new code to a server where the new-code is behind a disabled feature flag means the program hasn't changed. The feature flag can be enabled when it's suitable. (This could even be 'rolled out' to only a subset of users; e.g. testers, internal, 10% of users, etc.)
deploy = put the code on the server, release = enable the feature flags
hi, european here. Never heard about composting here.
Those are not vaults. Those are just holes in ground with a cover on top. It's mostly decorative and there so that you don't walk on top of the coffin.
We don't usually own these also. Usually city where you live has a cemetery that must provide a place for the coffin.
In Poland municipality provides a place in ground, but for at most 20 years. After that the place is recycled for another burial. You're free to buy it though to prolong that term and in my opinion it's quite common among the elder ones.
> In Poland municipality provides a place in ground
That would apply to municipal graveyard while church owned ones are managed separately. In either case, if grave spot fee isn't paid on time, space goes back to the pool while remains of previous "occupant" are transferred to the ossuarium - IIRC.
but with the size of the audience you're targeting there is no way this is going to be a memorable number. Keeping a contact book with these isn't a big step forward from managing the one already present on my phone
I'm not planning on it being memorable, and in most cases you will have a choice to use a global number or add this service(s) to your existing number.
I work for a shop with more than 200 devs. Over the years we had multiple efforts to standardize the libraries, platforms we use only to very limited success. While things like CI software and IDE got pretty much standard without any intervention to this day there is no consensus for library x to do y. The overall sentiment resonates with me and what I've seen at my workplace
