We could spend money to eke out a little around the margins like using more paid firefighters to do mid week burns. It’s not addressing the main issue, though. The climate is changing.
1,765 karma · joined May 9, 2011
https://notbad.software
We could spend money to eke out a little around the margins like using more paid firefighters to do mid week burns. It’s not addressing the main issue, though. The climate is changing.
All of my brigades trucks have iPads which are useful for accessing maps, running collaborative fireground apps like collector, firemapper or rfsBuddy, etc. All of these things are “nice to have” though. We don’t rely on it for anything we must have, because it fails from time to time.
We use apps like Rover and Bart to manage call outs. They’re great because we can see who’s responding, how far away they are, etc. We also all carry ancient pagers because they’re bulletproof and mobile phones aren’t. They’re served by a hardened transmission network where every tower has backup power in case the grid goes down.
Tech is great but in extreme environments like a wildfire I want to have a paper map with me and I want to know how to use it. Just in case.
That said, on this particular truck three people out of the crew of four were programmers. We thankfully pulled up the conversation about the merits of Jupyter Notebooks for BI tooling before the fourth crew member, who is studying forensics, got so bored her eyes rolled right out of her head.
https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
Is Google proposing this as a replacement? As a supplement?
I made heavy use of the FileSystem API in a cross platform educational application a few years ago, tripping over a really hairy memory leak bug in Webkit along the way. By the end of that project the API had been deprecated, but apparently now it isn't any more and instead it's experimental? I have no idea what that means.
All my production stuff is dockerised and running on GKE these days. Most are FROM scratch with a statically compiled go binary in there. Some are on alpine and there’s the odd bit of Debian here and there.
Your application doesn’t need logging until _right before_ you have a problem that is solved by logging.
I don’t use frameworks these days. I’m glad I was exposed to their ideas in the past. I’m glad that exposure shaped my current approach. A framework is one of the ways that experienced developers can pass their knowledge on to less experienced ones.
I ended up tracing my pain to lazy technique in my right hand. Sorted that out and I’ve been pain free for years. It was _no fun _ before I figured it out.
Why is that the targeted benefit? I would think the main thing to gain from online courses is the ability to disseminate knowledge and learning to a broader swath of students.
My weapon of choice is Xmonad on Linux but I've also used i3 and awesomewm and they've been good. I hear good things about Amethyst on OSX these days too.
I currently use https://materializecss.com/ over several products. It's been great, but I'm stuck on the 0.100.x line because the upgrade path was too difficult. It's also hasn't been updated since the first 1.0 release some time ago. Not complaining since I got what I paid for (it was free) but it's left me pretty anxious to find a replacement.
Salesforce's Lightning components are good but challenging to understand how to work with outside the walled garden. Zurb's Foundation UI is interesting but seems to want me to use whole page templates rather than components.
This looks like exactly what I've been dreaming of. I've put my money where my mouth is as I can't wait to have more components built out to a stage where I can start using it for real.
Thank you!
Sometimes the change is so trivial or type safe that it's not worth it, so I don't.
Sometimes I don't understand the problem well enough, so I learn more about it by doing some exploratory coding and prototyping. I usually come back and write a test after the fact.
Sometimes the project is on fire and I'm just throwing mud a the wall to see what sticks.
https://github.com/davidbanham/kewpie_go
I’ve been using it for years across multiple products.
I also built this for a client lately. It lets them interop their Haskell services with kewpie a bit easier without needing to write a native wrapper.
https://github.com/davidbanham/relay_runner
I used to use an esp8266 but replaced it with a Pi after a lightning strike destroyed it. The Pi is just so much easier to write software for and it's been no less reliable in practice.
The front end was React/Redux and we just wrapped the bits of markup we needed into React components.
Clubman is well tested (TDDish) software written in Go and hosted on Kubernetes (GKE) with payments through Stripe. It's done 6 bookings per second in real world usage and been synthetically load tested to 10x that.
Ski clubs are a small niche but they have very specific needs. There are _lots_ of booking systems for hotels but they're all geared towards filling as many beds as possible with people willing to pay (of course!) Ski clubs usually have rules to ensure all members get equitable use of the facilities while also trying to maximise utilisation. These rules can get very complicated with multiple classes of membership, multiple rounds of booking with different entitlements and limits on beds and guests, different rules for high and low season, etc.
Clubman implements a system of Rules based on Triggers and Actions. It allows clubs to reflect arbitrary sets of rules without needing to commission custom modules from the developer as with other systems.
Notbad Software is a one person operation. I've built Clubman over the last 12 months alongside consulting work and my other products. I'm very proud to launch it to all clubs today.