HN user

finnigja

661 karma

She'll be right, mate.

Projects:

Learning Python -- https://learnpy.dev

Is your site IPv6 ready? -- https://ready.chair6.net

Personal blog -- https://chair6.net

Social:

https://twitter.com/finnigja

https://www.strava.com/athletes/finnigja

Posts6
Comments8
View on HN

... one common reason is that security engineers are shared across a large company and it may be very expensive for them to learn the different testing frameworks used on many different projects

That's where the partnering part of the approach I'm proposing comes into it. The security engineer isn't off there by themselves trying to figure out it, but is working with somebody who's already familiar with the existing code base & testing frameworks.

also, independent review (without any exposure to developers' conceptions about what should be tested, or why, or how) may be economically justified because outcomes of security bugs are sometimes much worse than outcomes of many categories of ordinary bugs.

Economically justifiable perhaps, but that doesn't necessarily mean we shouldn't explore better ways of achieving similar outcomes.

Other reasons may include that the security engineers want to run a test that can't be expressed in your testing framework without a huge change to the framework, they may want to develop their test cases adaptively such that most of the tests turn out to be useless and the cost of capturing every test under version contol may be very high, they may want to run tests from a commercial testing product for which the license does not allow bulk copying of the tests into a customer's testing framework, or (if they aren't in-house engineers) their business model is that they won't tell you every test that was run unless there's an associated defect finding.

Yeah, this'd be interesting to experiment with. The accepted model of security testing being separate allows this uncoupling of tooling / process, but .. perhaps the outcomes of a more-tightly-coupled testing methodology would be better?

I don't think any of these points are blockers, more just factors to consider or trade-offs to balance when exploring alternative, less separate, approaches.

I'm building an interactive, web-based Python tutorial site intended to help with learning basic syntax. Originally it was for my kids who wanted to learn to code, but... might be useful to others.

https://learnpy.dev

The content needs some work, but I'm pretty happy with the framework / UX. I would love to get any feedback from folks who check it out!

(The first section is just multi-guess questions as part of the introductory content. Try any other section to get the full in-browser-code-execution experience, which uses client-side Pyodide under the hood.)

IPv6 Is Hard 1 year ago

Haven't look at that code for a while, but IIRC it does a simple HTTP request then checks the returned HTML for anything that looks like a v4 literal, eg. http://174.136.109.18.

Kiwi here - spent the first 25 years of my life in NZ (Taranaki and Wellington) but relocated to the USA (a year in the Bay Area, then just outside Seattle since 2007).

A few observations of factors that may be considered:

- Distance from markets impacts competitiveness of exports

- Distance from world / experience / culture / opportunities leads to exodus of young travelers (see "the Big OE", http://en.wikipedia.org/wiki/Overseas_experience) and braindrain

- "Tall-poppy syndrome" (http://en.wikipedia.org/wiki/Tall_poppy_syndrome) reduces visibility of or desire for success

- "She'll be right" culture (http://en.wikipedia.org/wiki/She'll_be_right); apathetic, relaxed, or optimistic?

NZ has a very strong entrepreneurial culture but perhaps the challenges above or wrong choice of markets to target make that less effective econony-wise than it could be? There's an interesting read on that at http://pando.com/2013/05/14/number-8-wire-entrepreneurialism....