mdtusz

> My notebook is full of unorganised notes that I jotted down when a lightbulb came to me one day, rough sketches or mappings of solution ideas, brainstormed lists of features etc.

This is to me the biggest benefit of using pen and paper, but it requires shifting your attitude towards pen and paper to treat everything you write as disposable. Just freely sketching out ideas and using paper as a place to dump thoughts without concern for quality, formatting, or even having them be cohetent, is probably the most productive way for me to solve problems - so much so that I have switched to using large post-it notes, rather than a notebook. The good notes stick around for a few weeks, and the bad ones go straight into the bin.

I know many will disagree, but I think the commentary on SR&ED killing momentum and motivation in startups is bang on, even though it's a nearly impossible thing to measure or quantify. I'm sure many fellow Canadians reading this comment can relate to the absolute draining feeling when you see that message "remember to update your SR&ED timesheets by the end of the week!".

Time tracking isn't inherently bad, or counterproductive, but I haven't once come across a startup that does their SR&ED reporting with an ounce of honesty. Timesheets are essentially fabricated based on either what the developers think their managers expect to see, or based on what the managers tell them to fill in, and it's entirely understandable - programming is not a job where tracking hours makes sense.

Rather than timesheets, it would make _so_ much more sense if instead, high level but detailed quarterly reports were made outlining what was completed, and if there needs to be more detail, an audit can be done. Timesheets kill productivity, motivation, and curiosity to try new things and accomplish actual research and development - what the SR&ED program is intended for. At the end of the day, it's the implementation of the program and the industry of consultants surrounding it that is flawed.

I'm convinced that the vast majority of business-y manager types that always trumpet "we have to be more agile" have never read the agile manifesto - specifically the "individuals and interactions over process and tools".

It's regretful that it caught on so well and has (incorrectly) evolved into a concrete process in most places rather than an ideology.

I've tried this a few times and none of the ovens I've had over the years have been successful in removing seasoning with their self-cleaning, so at this point I'm trying to find a machine shop that will be happy to bead blast it and mill the surface flat again. So far, most shops have given me quotes in the hundreds of dollars so I've been waiting until I meet someone that has the capability to just do it in their garage.

Most new cast iron cookware now has a raw surface with lots of pits and bumps from the casting process as well, which doesn't seem to get nearly as smooth and non-stick as "vintage" cookware.

Are you saying that the android auto code has access to the OBD2 bus (and possibly canbus)?

You wouldn't necessarily need to even drop much more than a mass that weighs more than twice the buoyant force of the buoy with a block to redirect the cable, then have a floating platform that's more buoyant than the sinking buoy.

Interesting idea.

How often are you verbally communicating primary keys/id's internally within an organization?

I've never understood arguments against guid's, except for table performance with databases that might take a performance hit because of either inserts, or because data won't necessarily be partitioned in the "correct" order (e.g. MySQL writes to buffer pools).

Anecdotal, but I've found rust much easier to grok and become comfortable to work in than I have with Go - partially due to the docs, but largely because of the perceived complexity in explicitly typing and handling of options and results.

With rust, I very rarely feel like the code I'm writing might not be correct for a technical reason, whereas with Go, I find myself very often having to think too much about how best to actually do something "safely" or "correctly" because it's inherently possible in a way that rust makes either impossible, or at the very least, warns you profusely.

I think you may be in a minority of people that intentionally turn their machine off at the end of the day.

I don't think I've intentionally shut down my desktop or laptop (excluding reboots and when leaving for travel) for years. Especially not laptops.

To me, this is mostly a solved problem for casual contributors using the web interface of GitHub (and I assume gitlab, Bitbucket, and others). If more "serious" contributions need to be made, learning the basics of how git works isn't that difficult - branching, commits, and merging are basically all that a novice user needs to understand, and they're pretty easy to explain concepts (even if it means you're telling White lies about how it works under the hood).

We don't expect the average person to understand the tools and workflow of a mechanical engineer working with SolidWorks PDM - we shouldn't expect the average person to understand git (which is basically the software equivalent). I've never disagreed with the arguments that git is confusing or difficult to learn for non-software-developets, but I've never really understood why that's a problem.

Another vote here for ThinkPads.

I have a t480s and an X1C for work, both with arch and they both run beautifully using the same configs and dotfiles on both (with a few minor changes around display resolutions).

They're solid machines if you get a good one and the keyboards are IMO the best you can get.

This can be a surprisingly useful tool at times - I've definitely used it to advantage when doing creative coding so that the graphic or animation is displayed behind my terminal and I can see and edit the code at the same time as viewing the effect without switching windows.

Of course, a second monitor can do this too and without the downsides, but sometimes you're away from your desk and it's a nice workflow.

Which is typically a function of sale price.

I've never really considered this before but it's interesting. Does this happen randomly or is there some geographic/tower based IP sharing?

This isn't limited to MBA's. There's plenty of (non-cs) engineers out there that are in high ranking positions, making decisions over areas of the business that they know absolutely nothing about.

It's not an MBA cult problem, but it is a management-academia problem. Universities provide classes about management and business without focussing on the actual business part of businesses. If you want to succeed, domain knowledge will almost always be the most important thing, and business and management schools basically brush this to the side as an afterthought.

This still requires a node runtime. As far as I understand, the deno usage creates a single executable - batteries included.

This would be an interesting use case for eBPF.

Fwiw, I have a 13" ThinkPad with a 4k display and get ~4 hours of real battery life or more while working with docker running a handful of containers, browser, vim, spotify, and a few dev tools running.

Nothing amazing by any means, but it's plenty for real world usage and if I stop the docker daemon, I probably gain another hour or two. How often are you working somewhere for more than a few hours without a plug?

Even with multiple displays it's not that difficult - just pass the scale you want for a given display when calling `xrandr` and things generally just work as long as you're downscaling from the "native" dpi you have X using.

This isn't really a problem in this case.

Housing in Vancouver is _incredibly_ expensive, and there's a huge amount of foreign ownership by rich people that leave the dwelling empty all the time, or maybe only live in it for a few weeks or months per year.

If someone is wealthy enough to own a property in Vancouver and not use it more than half the year, I don't have an ounce of sympathy for them being taxed for that. If they don't like it, sell the property, and rent an absolutely beautiful AIrbnb or house for the times that they are in the city.

Or just use plain old gpg and a git repo or backup service. Pass is good because it is roughly domain specific to passwords and secrets. I wouldn't exactly consider tax forms "secrets", but rather just private information. Adding everything private and the kitchen sink seems like a misuse, but if it works, it works!

I'm an avid pass user too, but I think claiming that managing gpg keys is _simple_ is a bit of a stretch.

Creating a single key on one machine is not hard. Following proper best practices for gpg using subkeys and setting up pass to work nicely on multiple devices is a bit more involved and requires a decent understanding of gpg keys in general, which (correct me if I'm wrong), even most developers aren't super well versed in.

Agreed that it's not a good practice security wise. This is what I argued against when the initial request was made (we also had over the air upsates) but it was interestingly the _most_ "security conscious" customers that had requested this - they specifically wanted us to mail them either replacement microSD cards (the disks on the machines) or USB sticks. The machines themselves verified the contents and we also offered a way for customers to download the images directly and verify, but most customers just opted for snail mail. /shrug.

Several of these companies also had strict email attachment filters that we were instructed to get around by just appending `.allow` to the filenames. There was tons of this type of stuff that we encounted which really highlighted that corporate security at many companies is just theatre.

Tinycore was used at my last job to get around some frustrations of updating the embedded systems on the machines we made (which ran a full blown Linux system).

We mailed customers USB drives that when plugged in would mount and start tinycore Linux, then write the new system to a parallel partition, reboot the machine, then run a few health checks.

Some might say it's hacky (it is/was) but it worked pretty well and allowed for recovery of totally borked systems.

I've never liked this explanation because most HFT is just front-running. The liquidity is there already, they're just shaving their cut off the top in most cases because they can move faster than everyone else.

Partially, but DOD like in the article examples work great when you have a "rigid" architecture like a game where having a struct to contain vecs/arrays of player attributes makes sense. This can break down when your "objects" require more flexibility and are used in multiple different contexts where an aggregate `PlayerState` struct doesn't play nicely.

Not to say that DOD is bad, just that it shouldn't always be the go-to choice. Rust _does_ make this sort of design much nicer to work with because you can in many ways have your cake and eat it too using `from` and `into` and go back and forth from DOD to OOP type structures.

I'm not sure why you think this but it is very incorrect. I can't speak for your Toyota, but most car headlight assembly's absolutely allow for replacing the bulbs inside them.

Your dealership may not tell you this because they're incentivized to sell you that 2k housing, but do some research and you will almost certainly find that you can replace the bulb for $50 or less.

> The first column of the rotation matrix is the new x-axis expressed in the old coordinate system, the second column is the y-axis and so on. An identity matrix would yield in no rotation since all unit vectors would be the same as the previous coordinate system.

It's a shame that this isn't made more clear in most tutorials and classes. The idea of axis application order really does make things more confusing than is needed.

I ordered one of the STM32 development boards when this was first published. It's fairly straightforwards to get basic blinky demos working, but it was about at this point that I ran out of steam, and you're basically left to fend for yourself, implementing anything more complex from scratch.

It may have changed since, but rust embedded definitely isn't hobbyist friendly unless the goal is to make things work, rather than to just make things.

We had this argument recently at my workplace and dug into the pros and cons of both, ultimately settling or regular merges and no squash.

The only real argument for squash-merges is that history remains linear and visually "clean", but if you want to see a "clean" history of only the merge commits, you just can just use the `--merges` option on the command line.

Squash locally if you really want to or need to, but I'm a firm believer of disallowing it as the merge method for a changeset.