It's not a thing I use everyday but sooo much nicer than having to unplug and lug my proxmox server up from the meter closet anytime there's an issue.
94 karma · joined June 1, 2011
It's not a thing I use everyday but sooo much nicer than having to unplug and lug my proxmox server up from the meter closet anytime there's an issue.
Also discussing the development of the ability/discipline and the difficulties in transcribing what you now intuitively know but need to describe to other mathematicians so they can understand (notation/equations).
It's a book that's stuck in my head since reading it and wondering how to apply some of this to other problem spaces.
The few times I ran one (was a sysop on a few, but remotely), I was always a little creeped out that I could see people typing messages, etc. Felt like invading their privacy.
Of course it's still really nice to just have C itself being updated into something that's nicer to work with and easier to write safely, but Zig seems to be a decent other option.
I got all the way to the final missions where you're writing your own assembly (that you created) to solve various programming puzzles. Only stopped because I got busy with something else and break was over. I def recommend it. Reminded me at the time of Code by Charles Petzold but applied.
(Last I checked the Author was rewriting much of it for performance reasons and to fix up a few gotchas that should be possible with circuits but aren't here - no idea if they still are but that was my understanding before)
Also remember that Shopify didn't start out making billions. They started as a small side project on a far, far slower version of Ruby and Rails.
Same with GitHub, same with many others that are either still on Rails or started there.
You can optimise things later once you actually have customers, know the shape of your problem and where the actual pain points are/what needs to be scaled.
To me, I care a ton about performance (it's an area I work in), but there's not a lot of sense in sacrificing development agility for request speed on things that may not matter or be things people will pay for. Especially when you're small.
I think of that whenever someone is angry about cookie banners. Like, that was just happening before without me knowing.
Now when I see that, often I just leave as this site is not a place of honor, no highly esteemed article is written here... nothing valued is here.
For me not being focused on finishing anything is what got me back into playing music (and eventually performing live sets).
Previously there was so much pressure to produce end results I couldn't even get started and lost all joy in the process. At some point I got some hardware to just play with and never really looked up how to save anything (was a Drumbrute, Meeblip and I borrowed a Beatstep). Was making odd acid tracks and silly sketches on my kitchen table every night that I'd lose as soon as I turned it all off. It was oddly freeing, and really fun.
A year later I was playing out gigs ranging from 20 mins to 3 hours. And one could even argue that I've still not finished any songs despite hours of recordings and performance as it's mostly improvisational.
Now I'm happily back in the noodling around and having fun stage again and loving it (though about to switch gears again).
Anyway - just figured I'd weigh in as there's often a lot of pressure to finish or record things when just playing around or building weird synths is in and of itself a really really fun (if expensive) hobby and maybe someone needs to hear that. :)
(also perfectly fine if your focus is on complete songs, of course)
Also the rights point you bring up is pretty key, the amount of protections, safety net, and rights you get as an employee in Europe makes it so that needing to save copious amount of money in case things go sideways is not a thing.
It can be hard to swallow at first, but when you account for lower rent, much cheaper health insurance, and far more vacation days (~20-24 by law - and no one actually expects you to be available) along with safer cities with generally higher quality of life, in my opinion it ends up being a very, very good trade off.
I moved to Amsterdam some years back (and have worked for a Berlin based company) and don't know if I could ever move back to the states.
Not to mention, that was certainly a trip down memory lane reading those emails (and cringing at many). Worth tracking down if you have one laying about.
Additionally those stats are often considered to be enormously skewed as one of the primary ways you can avoid a drug charge in some places is to "voluntarily" enter rehab for it. So while it looks like pot addiction is up, it is really that pot arrests are up.
This would also explain why in the study minorities seem to have a higher rate of "addiction", as they're more than twice as likely to be arrested for minor drug charges and thus more likely to be put in this situation.
Whoops.
Probably still have a floppy with it in storage somewhere. :D Thanks for making that!
If you ever did any development on packages, you may have a development version laying around preempting things. Check in ~/.atom/dev/packages and remove old versions (or git pull them up to the latest dev version).
I had a super old version of tree-view for a long time this way. :)
May be important to some legacy projects trying to get off of SF.
For instance there are a few PMs now for very involved projects, and we have engineering managers to make sure we're getting along ok and not falling between the cracks (turns out 100+ people reporting to one person can be tricky), but still remains enormously open.
Most decisions are made in the open (if they legally can be), there's almost always a Pull Request with discussion around it if you want to either take part or just see how that decision came around. The culture is pretty allergic to anything closed. People frequently ask for a URL if they're curious how a decision was made. This makes it much easier to not feel left out as a remote employee (which something like 60% are).
As an engineer I can largely still choose what I work on much in the same way as before: if there's a project spinning up and I want to work on that project and that team wants me and my team is cool with me going I can totally go work on it.
I've actually been encouraged to work on other things lately to get more perspective on the product and work with new people. I don't feel pigeonholed like I have in some other places.
Teams mostly self organize into structures that best work for them. Some teams look fairly traditional. Some use scrum. Some use some other agile methods. Some use nothing. Some work closely with a PM. etc. Use what makes you happy and what makes you productive. Different projects have different needs.
Things may shift around as growth happens (and they have), but largely I feel like the principles have stayed intact. Still the best place I've ever worked.
Me saying "replaced" is a bit of a misnomer though because the way we create, maintain, and configure Enterprise is totally different now making Chef and Puppet overkill for our uses. We no longer try to maintain the state of the entire system throughout upgrades instead favoring placing a complete system (built using mostly bash and again a bit of ruby).
Since we only now need to change a few configs we can do that using bash and ruby. This resulted in huge speed ups when reconfiguring Enterprise.
It's hard to over emphasize how much of the underlying way that Enterprise was put together changed and was improved with this release. Everything from developing on it, to releasing it, to deploying it, to upgrading it has all been shifted.
Huge respect to the infrastructure folks that made this happen (certainly made my life easier as a dev!).
He didn't notice, and it was amazing.
In cases where an account does have repositories (user initiated renames) the old URLs/repos will redirect as long as another user doesn't take the old name and create repos with the same name[1].
[1] https://help.github.com/articles/what-happens-when-i-change-...
Overall it's pretty painless, and the dormant users are thankful for the notification.
Amazing review at every step of the way.
eg hit https://github.com/mbostock/d3 then https://github.com/contact
Just reads a bit funny in the case of https://github.com/isaacs/github :)
I would expect these to be fixed by now, and for certain setups it simply wouldn't be an issue, but definitely put a bit caveat in "Use Puma!"
Performance wise we saw it actually be worse than Unicorn at my former company. There were a few issues but the biggest one was no out of band GC at the time, so GC time was part of the requests and something a user saw. There were some use cases where it should have destroyed Unicorn but still strangely lagged (threaded, high IO operations. Should have been able to do far more with less since Puma continues to serve while Unicorn workers will wait). Memory usage did seem better.
We ended up back on Unicorn after a few weeks of fighting. I would imagine it to be better now (no longer deal with servers at all, so no idea), but I found the dissonance between everyone heaping love on Puma at the time and the actual experience jarring.
It seemed like a fantastic project, but at the time only for certain projects and certain infrastructure setups while Unicorn was fairly bulletproof.
Of course all of this is old knowledge and with the people who are involved in the project I expect things are far better these days. Caveat lector and such. :D
Though the selections may be inspired by machines. Or rabbits. Hard to say.
Basically, the work is on-going and pretty amazing to watch!
Either way, being able to contribute back is definitely one of the things people are looking forward to about being on a current version. I've heard a few mention they'd love to be able to send any Rails performance bits upstream much like we see with the Ruby patches lately.