82 karma · joined December 29, 2021
The language server protocol understands the syntax of your language. There are also plugins for autocompletion, and a file tree for fast navigation.
Caveat - long term vim user just starting to dabble into this territory. Have got started with Telescope for fuzzy file search, and Nerdtree for file navigation.
If you'd like to work with real hardware, +1 to the Ben Eater suggestion. He sells kits for all the components for an 6502 machine so you don't get bogged down in sourcing them. Great videos too.
(Quick edit, not 8086, showing my inexperience with hardware!)
As an aside, one thing just came to mind. Even if you're bringing tech debt tickets into each sprint, there's a possibility they'll get picked up last - fine, unless they keep getting pushed back!
Part of me thinks this could be mitigated by reducing the velocity expectation. But there tends to be an overarching sprint goal relating to product work, and this often invites extra scope due to unforeseen impediments. So 'background' work like tech debt is easily pushed back.
I don't know of a better way. Perhaps it comes down to human factors such as limited focus.
This is all hard to do IMO if there's one running backlog.
The benefits of sprints I see is they're a useful time container for planning purposes. Eg:
- we can allocate larger pieces of work to upcoming sprints. This is done very loosely just to get some idea of what we can take on, and when
- we can allocate a fraction of each sprint to tech debt or platform improvements etc
- set a goal for each sprint which is some observable step forward. This has taken practice to break down the work into appropriate chunks which can be verified done
- record velocity across sprints just so we have a rough idea of what we can get done in a sprint (it will vary of course)
Yes, there is overhead from the planning meetings. But this helps all of us get involved with incoming work, which I think is better than tasks coming from nowhere without context.
I think the right methodology depends on the context of the business. If product teams need to work together towards something, or if there are competing project priorities, then sprints can help protect focus and provide finer structure than just "Q4".
So if AD were to be compromised, that would be significant impact.
There are of course advantages to such a "single point of failure" such as concerted effort in one place. But one way to mitigate the spof is transparency, and I'm reminded of LastPass versus Bitwarden.
As you say, sounds like interrupts are disabled while the open/close signal is being handled. Makes you wonder how it's handled in other models? Something physical like the lock you mention. Or maybe something in logic - like a series of flip flops? - to store and forward sensor actuations.
Hardware is fascinating but not when it goes wrong :-(
Stock for these seems OK, at least in the UK where I am based. It was ordered from Farnell. Mouser also have them in stock, but the situation may be different in other countries.
I was initially looking at the Arty board, as it was referenced by a text book - all the exercises were based on it. It's a bit more pricey than the ice40 (enough to force a comparison against other boards), but it certainly looks more capable.
Looking through the linked site, it's nice to see that the verilog snippets are very similar to the simplified HDL in nand2tetris - almost identical in how pins and parts are composed.
I'm looking forward to getting hold of an ice40 board as mentioned (with the SRAM). There's a project out there which implements nand2tetris on ice40, and these seem available at the moment for a reasonable price.
So now with this VGA project, that's two reasons to order that nice ice40 board :-)
Glad I mentioned it here, I now have a steer in the right direction - thanks.
Trying to gain access to the ZigBee network or hub is probably not worth the effort, compared to using a more open stack in the first place.
- have a great note taking system - personally I like anything which auto links to related notes, like a wiki. There's obsidian, but I use vim notes as I like vim and need to keep internal stuff out of cloud.
- get involved in cross team initiatives - will help build domain knowledge and relationships
- for digging through codebases one thing I'd like to try and haven't got round to is using a lightweight IDE just for hunting around and joining up the dots. Eg the main IDE I use is heavyweight with all the indexing it does. Sometimes I'd rather have a local "monorepo" with lightweight tooling which isn't always indexing or spawning daemons.
On that last point, get your tooling to work for you exceptionally well. Any friction will add up over time and discourage quick experiments or exploration.
Hope it goes well!
How about least privilege first, then try a build cycle and re-assess any missing permissions flagged up?
- Use diagramming to 'externalise' a problem if appropriate. This makes it easier to focus in on areas and to 'see' interactions more naturally. Also helps identify 'seams' to break out smaller pieces of work. Diagramming also works well in a group setting as a shared point of reference.
- Tackle the most poorly understood or risky elements first. In software, this could mean spiking code to explore uncertain areas to uncover complexity which might affect timelines or become a blocker later on. Prototype things in order to learn without needing to build everything out.
- Separate requirements into groups using MoSCoW - must haves, should haves, could haves, won't haves. Actively push the lower priority requirements later on the timeline (or as a later phase outside of the main project scope)
- Try not to get sucked into detail during upfront planning. It's true you'll need to work out the details anyway at some point, but without discipline you could end up taking a 'depth first' approach, and miss the wood for the trees. Domain complexity can be left to implementation time. See however the point on de-risking areas of concern.
- For team projects, consider running a session to capture risks upfront. Anything which could affect the timeline. Schedule check ins with stakeholders throughout the project. Also involve people early on from whom you may need support.
- Again for larger, or team, projects - consider keeping a decision log. Very helpful when you wonder 'why did we decide to do it that way, there was a good reason but what was it again ...'
- Break the project into milestones. A key deliverable in the real world, with a due date, for each one.
- Remember every project with any uncertainty is likely to overrun unless you bake in extra time for unforeseen problems. Trouble is, we only tend to plan for what we know about, and early planning phase is when we know the least.
- Identify external dependencies and get the ball rolling on those early on.
- For smaller (or personal) projects, keep an outlined list "Getting Things Done" style. Always have a next actionable thing noted down for each project. This makes it easier to cycle around different projects or areas with minimal context switch overhead.
There are more customisable products within Google where you can provide training examples and labels using a UI (AutoML I think it's called). The result is an endpoint you can use to do inference, based on the model created behind the scenes.
I just mention these examples because I've spent a little time researching them at top-level.
I mention it here as I hadn't thought about this beforehand, and many examples were given in that podcast of the advantages of property (bitcoin, real estate, barrel of oil) compared to securities (shares). Less potential for conflict of interest, stronger concept of ownership and stability over time.
One thing which has really helped me over time is finding focus amid the many motivations we all have. There's a really pleasant clarity which comes from knowing what I should be doing now.
Easy to say, but how? Personally I've found systems like "Getting Things Done" (the classic book) helpful - it emphasises getting things out of your head and into a trusted system. It doesn't even need to be GTD, I've moved closer to a "bullet journal" approach, as it's simpler. You don't want to overcomplicate things by being drawn too far into the productivity rabbit hole, as that carries its own time and complexity cost!
Some core elements of any good approach IMHO:
- a simple system you trust for tracking what's important (even if a prioritised list you carry over each day). This should contain simple meaningful, actionable steps. When things are "out there" it somehow feels easier to manage then when it's floating in my head.
- knowing the time cost of things. I saw a good video which suggested that if your life is divided into time buckets, then if one bucket grows too much (eg work) then another had to shrink (sleep, family, rest, etc). Quite an impactful perspective.
- keeping a "personal roadmap" for some longer range planning, but knowing it will probably shift as you go. Keep your "roadmap" in mind, review it consciously but don't be afraid to push things back or reprioritise.
- keep up an exercise plan (as others have said) - maintain your hardware!
- if you're feeling stressed or overwhelmed take a step back. You won't perform well in that state and you'll do a better job tomorrow. Or try to get help from others.