Kudos to the Gruaniad for stopping the BBC hanging itself. I think they should be allowed a small gloat off the back of this.
339 karma · joined October 25, 2013
Perhaps "banal" is the word you are meant to use.
There's a saying about that a 10 line PR will get 10 comments, but a 1000 line PR will get a "looks good!".
Of course this is not really what is happening. A 10 line PR can be completely unintelligible and a 1000 line PR might be a joy to read.
Once the code base has become a ball of mud, no one really bothers to review anything properly - it's going to take as long as writing it yourself. So perhaps, we get picky about some worn out code style point (incorrect indent etc) just to show we are alive.
If we are all quibbling over the wording used in a hypothetical case, then I wonder what's going to happen when the lawyers get going with the real one.
IANAL, but the general understanding is: "Ignorance is not a defence". If your legal advisors did not flag this up then I think you are probably entitled to ask for your money back when Apple kicks your butt.
1. How long it will take if everything goes well and according to plan.
2. How long it will take if everything goes wrong and we uncover further problems along the way. Probably getting those risks listed.
3. How long it is likely to take.
I imagine we tend towards doing just one of the first two, but having to do both should lead to more agreement on the third.
That said - its been about 30 years since I was taught this as part of critical path analysis, and I've never seen it used in the wild.
If we say that we don't know how long its going to take or how much its going to cost - can you blame them?
Lots devs like me have a comms issue. We would love to deliver stunningly brilliant complete package on the first attempt and we come across as secretive. We need to made to think about delivering an MVP and building a product up incrementally. This way those nervious bosses and investors can see that something is happening. I think the question is often not "how long is it going to take?", but rather "will you ever deliver something I can sell?".
When I first encountered "Project Managers" in the 80's they were still trying to fit this model to software development.
I truely believe that developing software is a creative process that you are always doing for the first time (unless you did it wrong the first time). Why does everyone expect us to know how long its going to take.
The basic rule of thumb I use is to take my best guess and multiply by PI. (answer: because 3 isn't usually enough).
That said, I didn't actually like early Maven that much, it was pretty inflexible and often required the AntRun plugin to do something novel. However, it is still top dog everywhere I work and very much the standard way to do things.
I ride with a friend who has gone MTB electric. I leave him behind on the flat but he gets it back on the hills. He's fine for well in excess of 40 miles. Range is mainly an issue of battery size not the wattage.
The biggest issue I see for higher priced bikes is secure parking (as mentioned in the article). No one provides secure/supervised parking and its tricky to get insurance. You can't really lock any nice bike outside the supermarket and always expect it to be there when you get back.
Standups don't work when the team isn't getting anything out of them. Perhaps we all know what's going on because its a small team and we all talk to each other. Perhaps. its because we don't talk to each other in or outside the standup. Reeling off a load of ticket numbers without challenge is not communicating.
From the article: standups aim to: "seek out and destroy misalignment". How can we do that without putting the mis-aligned on the spot and making them uncomfortable? I think standups start to fail when we're all being too nice and don't ask the awkward question. After a while we just stop listening.
For me it will always be the fat man standing behind a lamp post.
So often when I get involved in "REST" projects, I find URLs that include words like "update" or "add", or where the GET returns JSON with a completely different shape to that the PUT accepts.
Does it matter? If you don't cache anything - probably not, but it isn't REST as it was understood.
PUT replaces the entity or thing that has that url. If the entity didn't previously exist then it is created. A cache should be able to use the incoming entity and return it directly for a following GET to the same url (in the same way the entity returned by a GET might be cached). I don't think anyone would configure a cache to work like this any more - but that's the idea.
POST was the dynamic-web afterthought for anything that really didn't really fit into the website maintenance behaviour defined for GET, PUT or DELETE. You could send anything to an endpoint and it isn't cached. POST often gets used in REST to create an entity within a collection at the url, but really (in HTTP terms) anything goes. POST does allow for returning a cachable entity through use of a Location header.
PATCH came much later and its use in REST is debated. Originally it was intended to effciently update multiple text documents through use of a single patch (or diff) document in the body. From a HTTP/caching point of view it is effectively the same as a POST (i.e. this is not an entity so don't cache it). People use PATCH today because they want to partially update a larger entity, but HTTP and REST did not provide for this. How the body of a PATCH is to be interprited in REST is effectively undefined - its up to you, just as with POST.
Some prefer to do partial updates using PATCH for semantic reasons. Some like to use POST for syntactic ones. Some like to POST to a url extended to encode the part of the entity being changed (which is wierd but compatible with POST), and some wrongly do this with PUT.
Unless you can see functional issues (e.g. when a CDN somewhere sees a DELETE for a url and could assume it should now always return a 404), then it's probably best not to get too hung up on which verb to use.
For high volume sites we would cache at multiple levels. At the load balancer, on the CDN or in the browser - depending on how public/user-centric the data was. You would not expect a browser to return to the server every time for a 1 pixel spacer gif (oh the glory days), and you wouldn't expect it to keep retriving the user's name for the top of each otherwise static page.
However, things changed - the consumers of APIs were no longer browsers and the internet just got faster and faster. I can understand why developers just decided to forget about caching.
This is probably why most developers I now encounter just can't understand why the thing at the end of a GET or PUT url should be a "thing" not an operation.
There's no reason to believe that Æthelflæd was captured by vikings and impregnated by Erik Thurgilson before marrying Æthelred. Or that Æthelred was any more a misogynist than any other 10 century christian king. However, we can be pretty sure that Uhtred the bold wasn't even born at this point, never mind Æthelflæd's lover.
It strikes me that to build a useful location dataset, just one widely used app would be more effective than any number of niche apps asking for strange permissions. I would build an app that provides many people with a really useful service that obviously requires access to your location. So it would probably provide some sort of mapping or navigation service. To consistently collect data it might well force the user to have data enabled rather than just hold the map data on the phone.
Perhaps I could also shut others out of this lucrative operation, if I could just get my app pre-installed and enabled by default on every phone.
Just speculating - who really knows.
My colleagues and I have been grumbling for ages that our instance of Confluence must be really badly configured. If you put in a single word search term, there will be lots of results, but no guarantee that any pages containing that word in the title (or body), will appear above ones where it doesn't.
The search problem was solved long ago by Apache Solr/Lucene. Although this may not be true for multiple languages.
Pulled over, hood up, wiggled a few leads. Light goes out, hood down, back on the road, job done.
Yes, I think I detect a definate bias towards a Picasso/cartoonesque style :-)
Even Dr Stangelove is in colour.
I think our jobs are safe for the forseeable future.
On my own laptop I use Linux Mint Cinnamon. Installed when Windows 10 got stuck in a loop installing an update that wouldn't work. I don't miss much.