An oldie but a goodie. The site has been around since 2011. What’s great about this site is the general idea that you don’t necessarily need a framework (ie React) for everything.
“Never rewrite” is a popular cargo-cult that sprang from a well known blog article that made the rounds some years ago. The urge to rewrite can be a naive impulse for sure, but there are LOTS of cases where new and better technology can result in tremendous gains, or where a code base is simply too far gone to redeem. The biggest successes of my career have almost all been ground up rewrites of existing products using new technology or techniques that resulted in orders-of-magnitude improvements in performance and ROI. If you can make incremental improvements that’s great, but sometimes it’s just not possible to rewrite “a piece at a time” because there are no pieces, just one big ball of mud. To the original author: If you don’t rewrite this mess, your competitors will. I’d say: lay out the case for an overhaul, stand your ground, don’t implement any new features until you’ve got a clear path to reducing technical debt, and if you can’t get buy-in to an overhaul just leave. What you’re describing sounds like a textbook scenario for burnout and there are lots of other opportunities where you can work on things in ways that you’ll actually enjoy.
Sorry, but it’s not out of date. Based on very recent extensive travel and living there. But yes of course there are additional places to get cash (yubinkyoku etc) and various rail passes. The JR pass really is a nobrainer though.
Basically no. But if your company has a Japanese branch and is willing to transfer you there, then maybe. But be aware that visiting Japan as a tourist vs living and working there are very different experiences, and plenty of expats burn out within a year. Visit first, maybe do the digital nomad thing for a bit.
SevenEleven ATMs generally take foreign interac debit cards if you need cash (yen). Most places accept credit cards. When given the option on the debit card machine to pay in yen or convert to USD / CAD etc always choose yen, to avoid high conversion rates charged by the processor. Allow your credit card company to convert to your home currency at a much better rate. Get a Japan Rail pass. Pack lightly and hit a Uniqlo on arrival. Call hotels to book rather than using western-based online booking platforms whose prices are a lot higher, or use Jalan.net. Remember you’re a guest in a foreign country, stay humble and be polite, it’ll get you further. Seriously, get a Japan rail pass. Get an esim for your phone upon arrival using an app like Ubigi or similar (1 month with 10gb for ~$20). Be prepared for reverse culture shock when you return home.
Of course. Foreign keys are elementary. Try recursive CTEs. You can get ridiculous performance gains by not having to marshal data into the application space. It’s all about using the right tool for the job. If you’ve done solid system-level design then running migrations probably shouldn’t be the primary driver of your schema.
This may not be a popular comment, but if you have to ask, then no. In Canada at least, engineering is a regulated profession. No one can legally call themselves an engineer without a four-year Bachelor of Engineering degree from an accredited University and membership in the professional engineering body of the Province in which they practice. Doctors and lawyers are other regulated professions; one cannot simply call themselves a doctor, lawyer or engineer.
My first ever mobile app was an experimental bit of Android Malware. It got demo'd by my colleague at Blackhat [1]. I'm definitely not a hacker, but with a few basic tricks I was able to create a pretty effective trojan which we then injected into a popular game (again only for experimental purposes, it was never released in the wild). In our lab we had literally millions of samples of Android malware, but for iOS we had only two (which only worked on jailbroken phones). Fun times.
Excellent post, if only for the fact that its a great way to share "what works for me" at a time when most of our local JS/Web meetup groups have been put on hold due to the pandemic, or gone onto Twitch / Zoom, so its harder to have those casual "I'm really loving such-and-such" conversations now. Thanks for sharing. FWIW I also like the general keep-it-simple / YAGNI approach. I switched from TypeScript to straight up JSDoc and with the right IDE setup it works beautifully.
Nobody seems to be talking much about favipiravir, which seems a bit like not-invented-here syndrome. If it stood to make a lot of money for some US big pharma company I suspect we'd be hearing more about it.
After using TypeScript for the past couple of years, I've come to see it as simply another "embrace and extend" maneuver by Microsoft carve off a chunk of JavaScript mindshare, preying upon the naïveté of less-experienced developers who've fallen for the "static typing is safer" myth. TypeScript's decision to disallow JSDoc within .ts files [1] for example doesn't contribute anything positive to my impression of this syntactic pocket-protector. While the type hinting it provides is useful, the tradeoffs of added complexity, tool dependencies, and cross-compiling phase have made it more trouble than its worth in my opinion, particularly since tooling to provide code introspection and type hinting has already existed for a long time [2]. For new projects, I've begun using straight JSDoc, which is working beautifully with minimal setup [3] and provides all of the benefits I ever found useful about TypeScript, while remaining completely unobtrusive otherwise[4].
As a pianist, latency of 20ms makes an electronic keyboard instrument unplayable for me. I wasted lots of time messing around with different drivers for soft synths trying to get below that number. 100 ms is a lot. In audio, a 8ms delay has an effect you can clearly hear, and can be used to "widen" tracks or simulate stereo from mono sound sources, since 8ms corresponds roughly to the amount of time it takes a sound wave to travel from one side or your head to the other.