I found Scrum’s iterative approach very beneficial. In every other project without it or some other bastardisation of “scrum” there was always a major fuck around with wrong priorities, and constant reacting to every manager. Theres no point taking on Scrum if you only think it means story points and standups. In any case, I ask what frameworks (that i can read about) have worked for all of you?
As others have mentioned, make sure you understand the difference between git an github.
The way I built an understanding of git was to create a local git repo, and start working with some plain text files. I tried the various commands - add, commit, branch, merge, and observed what happened to each file. Take this a step further and start working with a remote - you can use github.
This is how I built a mental model of what git and its commands do.
> That's how it happens: a tiny little change flings the door wide open. Someone solves their own local problem and misses the bigger picture.
feels like an opening to say "...which is why we mandate code review to try and prevent situations where a single person's lack of perspective gets shipped." Of course, that's banking on the reviewer(s) having a broader perspective, so it's only a probabilistic mitigation, but it beats nothing.
Unfortunately, most companies use an organisational model where the reviewer comes from the same team as the author, and hence tends to share many of their assumptions about the system under modification.
Code review only works well to prevent this sort of thing if you have designated owners for each library/feature, who are on the hook for the robustness/security/privacy thereof, and whose signoff is mandatory.
The moral is the importance of language-theoretic security: http://langsec.org/
>LangSec regards the Internet insecurity epidemic as a consequence of ad hoc input handling. LangSec posits that the only path to trustworthy computer software that takes untrusted inputs is treating all valid or expected inputs as a formal language, and the respective input-handling routine as a parser for that language. Only then can any correctness guarantees be assured for the input-handling code. Ambiguity of message/protocol specification is insecurity; ad hoc parsing is an engine of exploitation; overly complex syntax can make judging security properties of input impractical or even undecidable.
>LangSec explains why ad hoc "input sanitization", "sanity checking", and other advice to be more careful with inputs is not enough, and why numerous secure programming initiatives have not ended input-driven exploitation. LangSec is also a code and protocol auditing methodology.
From the title, it’s sounds like that it’s implying that because a unit test was fixed, holes opened everywhere. Which was not the case. The problem was lack of review.
Yes. The trick is getting it to release ions to be carried away by the wind without expending too much power doing it.
Thus far people seem to have been making cathodes like in vacuum tubes, using heat or high voltage to drive electrons out of emitters like you see in ion-generator room-air cleaners.
That might be a dead end, from a complexity, cost, and power waste standpoint. On the other hand, maybe maintaining a second grid at high voltage relative to an emitter array could be simple enough, with just one charge pump for the whole system that need not burn much power.
But a purely passive, air-friction driven system ought to be more foolproof.
Probably either would work, so it just comes down to cost and extraction efficiency. A single active grid that can capture a high fraction of the available power (up to theoretical maximum around 30%) might end up better that a whole bunch of stacked, cheap, passive grids.
The materials science needed to make the somewhat-conductive, hydrophobic, passive-grid streamers that readily give up electrons to colliding air molecules seems within reach, but that is not a thing I know enough about.
