This is not the only argument in this piece — I'd even argue that it's a minor one. It hardly makes sense to discredit the author and this article based on this GitHub misconception.
The free floating anxiety and dislike of the article is a symptom of an architectural/mgmt mistake in the article.
OK so there's a new long complicated extremely labor intensive elaborate detailed process. "Surely there had to be a better alternative?" Yes, yes there is. Unfortunately there are many options.
Now the correct answer would have been simplicate and add lightness. Agile manifesto "Individuals and interactions over processes and tools".
Instead, they found an overwhelmingly clunky and complex (their words not mine) tool to automate the complexity, or at least temporarily abstract it away, or at the very least replace one pile of complexity with another (larger?) pile of complexity.
Lets try a less controversial topic. Getting a pencil. All workplaces have different policies for office supplies. Order your own just like you buy your own clothes. Here's your annual office max gift certificate buy whatever you want. Here's a key to a supply closet. But here, we implemented a 15 page process involving teams of employees reviewing and documenting each individual request for a pencil in meetings. That's the bad news. The good news, is we replaced the original 15 page process with a 5 page process by installing an IBM mainframe, DB2, CICS, and writing a simple COBOL app that allows end users with newly installed 3270 terminals to request a pencil, and now we're better off than "ever before". Now most people would have handed out GCs, given out supply closet keys, or just trusted the employees, so you're going to get all kinds of semi-off topic blowback about how the COBOL program should have been the flavor of the month CRUD web JS framework, or instead of DB2 they really should have used nosql on the cloud so they can scale office supply request to all 100 employees not just a small team. But the real problem that everyone is squirming about is they're doin' it all wrong.
My main point here is that on GitHub, making a pull request is super easy. There's even a cool pop-up if you visit the main page of a repo after pushing to a branch that asks if you'd like to make a pull request.
Saying that this is somehow more complex than updating a single commit and learning a whole new tool doesn't change that if you want to convince me, you at least need to correctly identify what's going wrong.
Perhaps if the author had specifically called out their perceived failings of the very latest GitHub pull request changes I'd have given the article more time. But unfortunately the justification given for switching was really shallow.
Interesting. I normally try to stay away from the "logged in context" when I'm defining API endpoints since it limits what can be done with the API. I try to define the API for data, and let the consumers decide which data they want to show, as long as they can access this data. For instance, it could make sense for admin users to see other user's cart, but this design makes it impossible.
I would normally go for something like `/cart?user_id={{id}}`, forcing API consumers to pass in the `user_id` (possibly reluctantly defaulting the value to `current_user_id` for convenience.)
This design doesn't necessarily make it impossible, but it requires a little redundancy. An /admin/ set of paths could cover the administrative needs, including viewing users' carts.
Well done. I always have a very bad time when trying to figure out which movie I want to watch, most websites have bad navigation / filtering capacities / just unfriendly in general. Movieo solves that problem elegantly.
Other solutions are interesting, yes, but HighCharts is an incredible product with a LOT of features built-in. I've built a reporting tool on top of it and it covers a lot of use cases. Building the same visualization with another tool would require a lot of time, thought and iterations to make the API as simple.
For my use case, it's totally worth every single penny.
Both are viable. We use a contractor that takes a cut (~25% for < 25k claims, 20% for bigger claims IIRC), but I know of companies that do it themselves and hire a SRED specialist to review their application on an hourly contract.
It's actually 80% of the salary for any work that has been done in R&D, but like you said, most of the work isn't.
A few years ago a lot of stuff could be considered as work "between two uncertainties", including non-engineering work such as graphic design, but the rules are much more strict nowadays. I think they still give credits for things that are way too simple to be R&D (ie: normal problem solving), but we've been doing [small] claims for the past 3 years and the rules have been tightened a lot.
Also, doing a claim requires you to provide evidences that you were following a certain R&D methodology. It's definitely worth it, but it's a pain.
I have to disagree there. A workplace that emphasis on fun at work does not imply bad code quality, nor does it imply good code either. Not sure what the fuss is about ping pong.
