desc · HackerTrans

4 jaar geledendiscuss

Apropos of nothing, and anecdotally: 2 years seems to be about the length of time it takes for a solution to become the next problem.

desc

5 jaar geledendiscuss

It depends how you count the unit/integration tests, really.

If you've got a general rule which must apply across an entire system, generate the necessary tests so that they fail granularly and don't require messing around to find the exact case which breaks. IMO that's one test, just applied to a range of cases.

An example might be mappings for Entity Framework (or similar ORMs, etc). Auto-generated migrations simply do not work if you need to limit migration downtime and maintain certain data invariants (which can't be specified in the schema, and yes, those always exist). So you need to write database migrations manually. This introduces risk of desync of entity mappings and schema.

So don't just spot-test roundtripping entities (a nontrivial system will have hundreds and something always gets missed). Instead, write a tool to introspect the DB schema and the Framework's mappings, and check that they match sufficiently closely. Every time someone adds an entity or property or something, it's already covered.

Similar cases exist when dealing with any interface between separate systems, especially when you don't control one of them. If you're regularly mapping between two models, use something like Automapper which can be asked to verify its mappings to check that every property is handled in some way.

(Granted, Automapper doesn't catch everything, but it builds a model that could probably be introspected over to spot encountered bugs and check that other possible examples of those bugs don't exist. Doing so generatively catches future additions of possible cases for free. If you're really paranoid, define some means of marking manually-written tests which cover each case, and test that a test exists for each case.)

Computers are really good at force-multiplication. They should trivially be capable of spotting other instances of known categories of bug. This is not hard to do and doesn't require wooly nebulous machine-learning shit: we've had introspectable ASTs since the dawn of compilers.

desc

5 jaar geledendiscuss

Ugh, when will they learn.

I actively DO NOT WANT this stuff.

* Not 'I want something else they haven't built yet and this is irrelevant'. * Not 'I don't understand this and just want something they think it already does'.

I mean: the entire concept of a universal Cloud account sharing an 'experience' across multiple devices is something I will gladly pay to avoid, as will the majority of people I know who aren't in IT (and can't necessarily afford the time/money/attention it takes to get away from this shit these days).

The people pushing this shit are either stupid or malicious, and either way they need to be removed from any position of control as soon as possible.

desc

5 jaar geledendiscuss

Silver bullets. They don't exist.

Code review. Read the results of someone thinking through a process. Spot more than they will, simply by throwing more eyes at it. Actually fairly effective: getting a senior dev to cast even a lazy eye over everything gives more opportunities to discuss Why It's Done This Way and Why We Don't Do That and Why This Framework Sucks And How To Deal With It with specific concrete examples which the other dev is currently thinking about. But it's still easier to write the code yourself than review it, and things still get missed no matter how careful you try to be, so it's still just another layer.

Unit tests. They cover the stuff we think to check and actually encountered in the past (ie. regressions). Great for testing abstractions, not so great for testing features, since the latter typically rely on vast amounts of apparently-unrelated code.

Integration tests. Better for testing features than specific abstractions, and often the simplest ones will dredge up things when you update a library five years later and some subtle behaviour changed. Slow sanity checks fit here.

UI-first automation (inc. Selenium, etc). Code or no-code, it's glitchy as hell for any codebase not originally designed to support it; tends to get thrown out because tests which cry wolf every other day are worse than useless. Careful application to a few basics can smoke-test situations which otherwise pass internal application sanity checks, and systems built from the start to use it can benefit a lot.

Manual testing. Boring, mechanical, but the test plans require less active fiddling/maintenance because a link changed to a button or something. Best for exploratory find-new-edge-cases, but throwing a bunch of students at a huge test plan can sometimes deliver massive value for money/coffee/ramen. Humans can tell us when the instructions are 'slightly off' and carry on regardless, distinguishing the actual important breakage from a trivial 2px layout adjustment or a CSS classname change.

So that's the linear view. Let's go meta, and combine techniques for mutual reinforcement.

Code review benefits from local relevance and is hampered by action at a distance. Write static analysers which enforce relevant semantics sharing a lexical scope, ie. if two things are supposed to happen together ensure that they happen in the same function (at the same level of abstraction). Encourage relevant details to share not just a file diff, but a chunk. Kill dynamic scoping with fire.

Unit and Integration tests can be generated. Given a set of functions or types, ensure that they all fit some specific pattern. This is more powerful than leveraging the type system to enforce that pattern, because when one example needs to diverge you can just add a (commented) exception to the generative test instead of rearchitecting lots of code, ie. you can easily separate sharing behaviour from sharing code. Write tests which cover code not yet written, and force exceptions to a rule to be explicitly listed.

UI testing is rather hard to amplify because you need to reliably control that UI in abstractable ways, and make it easy to combine those operations. I honestly have no idea how to do this in any sane way for any codebase not constructed to enable it. If you're working on greenfield stuff, congratulations; some of us are working on stuff that's been ported forwards decade by decade... Actual practical solutions welcome!

That's my best shot at a 2D (triangular?) view: automated tests can enforce rules which simplify code review, etc. The goal is always to force errors up the page: find them as early as possible as cheaply as possible and as reliably as possible.

The machine can't check complex things without either missing stuff or crying wolf, but it can rigidly enforce simple rules which let humans spot the outliers more easily.

And it is amazing how reliable a system can become just by killing, mashing and burning all that low-hanging error-fruit.

desc

6 jaar geledendiscuss

This.

Jira is a framework for building something which approximates your actual processes.

> Justin said “I wish Atlassian would sit down with real-world developers and design this product the way we need it to work.”

The way 'you' need it to work. The process 'you' use. I suppose it's possible to build a business on creating a completely bespoke ticketing system for each company which uses one. Over time, that business might gravitate towards building a general toolkit which can be configured for each use case...

Oh look! Jira!

I'd bet that everyone's got their own distinct idea of where subtasks, ticket relations, etc actually fit in their workflow.

The article clearly exists to sell LinearB's product, which will of course work great for people who have the specific problems LinearB are solving with their product.

The rest of us will configure Jira within epsilon of 'works', then spend an afternoon reading about APIs and bash out our own automation service to update X different management tools appropriately for our workflows, and then go down the pub to bitch about management.

desc

6 jaar geledendiscuss

Some other commenters have mentioned environment variables as input.

IMO there are broadly two types of command: plumbing and porcelain. There's a certain amount of convention and culture in distinguishing them and I'm not going to try to argue the culture boundary...

For the commands which are plumbing (by whatever culture's rules), the following apply:

* They are designed to interact with other plumbing: pipes, machine-comprehension, etc

* Exit code 0 for success, anything else for error. Don't try to be clever.

* You can determine precisely and unambiguously what the behaviour will be, from the invocation alone. Under no circumstances may anything modify this; no configuration, no environment.

For the commands which are porcelain (by the same culture's rules, for consistency), the following apply:

* Try to be convenient for the user, but don't sacrifice consistency.

* If plumbing returns a failure which isn't specifically handled properly, either something is buggy or the user asked for something Not Right; clean up and abort.

* Environment and configuration might modify things, but on the command line there must be the option to state 'use this, irrespective of what anything else says' without knowing any details of what the environment or configuration currently say.

To make things more exciting, some binaries might be considered porcelain or plumbing contextually, depending on parameters... (Yes, everyone sane would rather this weren't the case.)

desc

6 jaar geledendiscuss

I meant that 'creating' is rather the wrong tense, and that this is probably a symptom that it's pretty well entrenched by now.

desc

6 jaar geledendiscuss

88. If the signaling value of a college degree is its most valuable part, then we are creating a society that values the appearance of success more than actual success.

Someone might be a bit confused about where the causality arrow is pointing.

desc

6 jaar geledendiscuss

I prefer to internalise useful ways of thinking rather than leaning too much on tools, on the grounds that the latter are easy-come-easy-go while the former can last a lifetime.

Learn to explain what you're building, why, and more-or-less how it works in a context appropriate to the listener.

(Related: write things down. Again and again, differently, until you understand them.)

Problems and their solutions usually have similar structures.

Any fix right now might save a lot of money. The right fix next week could save years. Often both are appropriate, but the latter is nearly always most valuable.

The world does not change nearly as fast as your competitors want everyone to believe it does, but people's beliefs can.

A tool which warns you of possible mistakes before consequences occur is always more valuable than a tool which tries to guess what you meant and does that instead.

desc

6 jaar geledendiscuss

This, most of all. Substitute native language if not English; the important thing is that the project be defined and developed in both a human language and a computer language, so that mismatches can be identified and resolved.

  * Start by describing what you are trying to do.
    * Specifically.
    * Not 'build a web business to enable users to achieve their
      potential', not 'create another library for X but simpler'
      but *specifically what the software will do* and, most
      importantly, the priorities of scope increase (it'll happen
      anyway; just get the priorities and their order down in
      text ASAP).
    * Put it in a readme.txt or something.

  * For any given subsystem of the code (meaning: any section
    which can sort-of stand on its own) write another such file,
    in more detail.

  * Let these files guide your tests too.

  * Keep them up to date. If priorities change, *start* by
    updating the readmes. The code isn't immutable; nor is the 
    plan. But the plan comes first.

  * When unsure how a new subsystem or feature is going to work,
    write out your ideas and thought processes in text. Don't
    start coding at all for a day or two after you sketch out the
    basics. *Append* to this file instead of replacing large
    parts.

[edit] Wasn't intended to quote that part (sorry to mobile users) but I can never remember how to get bulleted lists on this site...

desc

6 jaar geledendiscuss

You mean like the OS is supposed to be?

desc

6 jaar geledendiscuss

1. Our customers run our software on their own machines for security and data-control reasons. As soon as something's running on someone else's hardware, the data is out of your control. Unless you're going to accept the (often massive) cost of homomorphic encryption, AND have a workload amenable to that, it's a simple fact.

2. Everything we do in house is small enough that the costs of running it on our own machines is far less than the costs of working out how to manage it on a cloud service AND deal with the possibility of that cloud service being unavailable. Simply running a program on a hosted or local server is far far simpler than anything I've seen in the cloud domain, and can easily achieve three nines with next to no effort.

Most things which 'really need' cloud hosting seem to be irrelevant bullshit like Facebook (who run their own infrastructure) or vendor-run workflows layered over distributed systems which don't really need a vendor to function (like GitHub/Git or GMail/email).

I'm trying to think of a counterexample which I'd actually miss if it were to collapse, but failing.

desc

6 jaar geledendiscuss

https://stackoverflow.com/questions/898489/what-programming-...

Most languages have context-free syntax, which is what the article refers too. There really is no reason to sacrifice that. Even modern PHP recognises the value of having a parse tree independent of an entire compiler.

Context-free semantics is an entirely different matter, and I'm not even sure what it'd mean...

desc

6 jaar geledendiscuss

Hmm, so the reusable bit is the straightforward inject-everything component, driven by an app-specific, app-aware hook-using part?

I can see how that can work for simple cases. Nesting components is going to get tricky though if the classes don't operate exactly the way the hooks expect.

Of course that's the problem: someone built hooks for their trivial cases and now they're the 'preferred' approach...

Edit: To clarify, 'simple' is going to be context-dependent since hook behaviour is. If your 'driving skeleton' of hook-based components is in the direct uninterrupted ancestry chain of every class component, you're probably using hooks in a near-ideal case.

desc

6 jaar geledendiscuss

I'm going to express something a lot of people are thinking and are being far too diplomatic about.

React Hooks are a fucking stupid idea and always were.

They're basically just adding dynamic scoping to a language and framework which doesn't need it, in one of the most 'magical' and confusing ways possible. You have to care about execution order to understand exactly how they'll all work and that will bite you eventually if you're building anything without knowledge of all the contexts in which it's called.

There's a reason that most languages stick to lexical scoping: you can see the dependencies, in the same file.

And a large portion of the value of functional languages is that they avoid state, making magic-at-a-distance impossible.

Boilerplate is not the problem. Magic is the problem.

desc

6 jaar geledendiscuss

Bad shit happens to a minority of people every day, permanently disrupting their lives and forcing them to abandon long-term plans. The majority remain oblivious and see an enduring status quo.

Suddenly a Black Swan craps on everyone at once, and a great many people are whining 'why is this happening to me' and 'when will someone fix this so I can go back to my routine'.

Guess what? Your routine is probably fucked. Throw it out, get used to the new normal, and accept that no one knows how to fix this (yet?), just like every other time we get hit by a context-changing problem.

Of course some people get too attached to their context, and those who come later and find their remains might label such events as 'out-of-context problems'...

desc

6 jaar geledendiscuss

Then you charge a reasonable price. You don't put a 'free' sticker on it with an unknowable 'ad revenue' cost in the background.

One might argue that the customer should know the price they pay in advertising data-scraping before logging in, these days, but we still convict people of fraud for taking advantage.

Advertising revenue is fraud.

desc

6 jaar geledendiscuss

"People don't consider my games worth what I spent to make them, so I'll sneak in adverts too so I don't have to charge them more and pop their little bubble, so they can continue thinking games are this cheap because the sticker price is still low."

No, this is not acceptable, and holding it up as a Good Thing that it's being perpetuated is stupid.

Microsoft have seen the writing on the wall (because it's been there for, I dunno, at least a decade?) and are saying 'you have to have an actual workable fucking business model now, k?'

desc

6 jaar geledendiscuss

Indeed, and this was measured, and the improvement was worth it. Profiling! :P The cost isn't always where we think it is.

Still, 'turn off exceptions because exceptions are slow' is a daft rule of thumb for the majority of software, where the slowness probably has more to do with choice of data structures, etc than compiler/platform implementation of language features.

Always measure first, last, and in between.

desc

6 jaar geledendiscuss

sigh If your application is slow, odds are it's not because you used exceptions.

If you're throwing enough exceptions for this to matter it'll show up on a profiler, and then you can change that specific chunk of code to avoid treating that particular case as 'exceptional'.

comments