katet
Joined 10 years ago
Joined 10 years ago
A: Why is drinking coffee every day so good for you?
B: Why is drinking coffee every day so bad for you?
Question A responds that it has "several health benefits", antioxidants, liver health, reduced risk of diabetes and Parkinson's.
Question B responds that it may lead to sleep disruption, digestive issues, risk of osteoporosis.
Same question. One word difference. Two different directions.
This makes me take everything with a pinch of salt when I ask "Would Library A be a good fit for Problem X" - which is obviously a bit leading; I don't even trust what I hope are more neutral inputs like "How does Library A apply to Problem Space X", for example.
Type markdown, build in docker, publish assets to GitHub Pages :tada:
(I know the Commons can override the Lords if it wants to, but it's not at that stage yet)
GP has a certain - admittedly orthogonal - point. At what point does "just two coffees per month" translate into "too many coffees traded for services"?
If it's relevant, a fairly high-end black coffee made from medium-roasted in-house coffee beans - which I strongly enjoy - costs me $1.70 in my local economy.
So this costs me 5x coffees, or a work-week of coffee. And I'm a pretty well-paid foreigner living in a strange land.
If I were to take a charitable reading of the GP - with no expertise in economics on my side - I'd say they were pointing out that you are potentially losing a 65+% of your market for whom $9 is not "a couple of coffees".
That's not an indictment - maybe you don't care! Maybe 100x customers @ $9 = $900/month and the service pays for itself.
I am a big fan of what I think is Purchasing Power Parity (PPP) / Pay What You Can (PWYC), even though I see it pretty rarely.
I guess it depends on whether you want to provide your product/service to as many people it can benefit at once, versus the minimum number of people who can support your costs with a profit.
Neither position is inherently "wrong"/"privileged", they just seem to have different incentives and/or target markets.
The voice of a potential target market that is being excluded seems valuable to me - even if the revenue increase might be negligible per-user, perhaps it's worth considering the volume of potential users in that market :shrug:
(To re-iterate that I'm trying not to pick a side here: maybe it's not - maybe the business model is to target affluent consumers. That doesn't make criticism of the exclusionary nature of this approach "privileged", however, in my view. YMMV)
(Edit: minor emphasis)
It was started as a pet project for development knowledge, specifically migrating to local Docker-powered development environments. Initially that was all it had: the "how to set up the Dockers" page and a couple of other tidbits.
Over a period of time - years, frankly - it has grown into something a bit more useful, although still woefully short of where I would like it to be.
A few things have happened though:
* The first principle was: if I find something I have to "re-discover", document it
* The more it grows, the more useful it becomes. It's quite pleasing to be able to respond to a Slack message with "read this and tell me if you still have any questions"
* It's still slow going, but after some departures ourselves, we've seen a bit more interest in adding and codifying the "tribal knowledge"
The best things I like about it?
* It's statically hostable: GitLab/GitHub Pages, or if you need to wrangle it, `scp`/`ftp` it from a CI pipeline with a private Apache/NGINX deployment
* It's Markdown text embedded in the repository: you can grep it, or search it from VSCode/Sublime/any-IDE-of-choice
* It's Markdown text embedded in the repository: there's no way I can think of to make it easier for devs to contribute and maintain it than making it part of the same commit, the same MR, the same CI pipeline
* It's Python. Every Linux/OS X machine has python, so there's a minimal barrier to entry for previewing locally
* A bucket-load of plugins: Mermaid, PlantUML, SVG embeds, and more: https://github.com/mkdocs/mkdocs/wiki/MkDocs-Plugins
* The "Material for MkDocs" theme: https://squidfunk.github.io/mkdocs-material/
Nothing stops it becoming just as much of a mess as Confluence, but there's something slightly ineffable about being able to work with your docs as if they were code: refactor them! Reorganise, dedupe, and take MRs to fix stale articles/mistakes.
Other commenters have mentioned incentivising the docs, but I would finally add that someone, somewhere should take a principled stand around the organisation of the docs (and of course, give them space to fail, and experiment, and try again). Broken links are better than no links in the first place, since search is pretty accessible.
I was originally inspired by the documentation structure outlined at https://documentation.divio.com/ - although our organisation has evolved away from this into higher-level topics with subsections similar - but not identical - to the original idea.
Edit: as for the comment about Confluence, this is one of my favourite bits. You don't need "buy-in" for this, there's no subscription plan you need to approve.
If there's a concern around "split-brain" docs, I've used a guiding principle to defuse those conversations:
"Do these docs make sense if you don't have a local checkout of the repository?"
If the docs aren't related to the code repository - RCAs, business requirements, org charts, HR procedures - leave them in Confluence.
If they are related to the repository - coding standards, test coverage generators, docker/unit test commands, migration seed data - then what's the value-add for them being in Confluence? Your CEO isn't going to read them. Marketing don't need them. Put them in the codebase, and reduce the signal-to-noise in Confluence for the rest of the business.
He took a risk (potentially, maybe he's the founder, maybe it's equity) and it paid off. It could just as equally not have.
There was lengthy discourse between the two men on which of them was more honored to be in the company of the other, followed by exhaustive discussion of the relative merits of the different teas offered by the proprietors, whether the leaves were best picked in early or late April, whether the brewing water should be violently boiling as the pathetic gwailos always did it, or limited to eighty degrees Celsius.
My two main annoyances are a) GraphQL could be thought of as a custom media type that almost "slots in" to the REST model by defining a request content-type and a response content-type with almost entirely optional fields, and b) the incessant idea that REST has to replicate the n+1 query problem.
For a) "it's strongly typed" has never struck me as much of an argument. It's appealing if you're already lacking a strong definition of your data model, but GraphQL doesn't inherently fix that, it just forces you to confront something you could fix within your existing architecture anyway.
For b), it seems that people tend to map something like /users to `SELECT * FROM users`, and 12 months later, complain that it's retuning too much data, and they have to make N queries to /groups/memberOf.
Am I alone in thinking the obvious solutions are to i) add a comma-separated, dot-notation `?fields=` param to reduce unnecessary data transfer, ii) add an endpoint/content-type switch for `usersWithGroups` and iii) realise this is a problem with your data model, not your API architecture?
As an additional c), my other concern is GraphQL touts "one query language for all your data", but tends to skip over the N+1 problem when _implementing_ the queries to disparate data sources. If your existing queries are bolted into `foreach (input) { do query }` then GraphQl isn't going to give you any speed up, it's just going to give you slightly more simplicity to an already-slow backend.
Granted, I work with "legacy" (i.e. old but functional) code, and I secretly like the idea that adopting GraphQL would force us to fix our query layer, but why can't we fix it within the REST model?
(I happen to be about to sleep, but I am genuinely interested in waking up to see what HN thinks)
However, it seems to me - as a layman with zero accounting experience beyond Wikipedia and GnuCash - you could feasibly drop an accountant into any arbitrary business and they would eventually find their way around the cash flows, balances, and - given sufficient information - build up a general profit/loss and general idea of financial health.
It doesn't seem to me, however, that you could drop any software engineer into any arbitrary company and expect the same. You should be able to, but not right now. Some software engineers can do that. Not all of them.
I suppose my point being: a degree from a chartered accountant indicates a core level of competency to me. But a software engineering degree doesn't. This is why we interview them with whiteboards / fizz buzz / how many windows can you wash / what is the ideal shape of a manhole cover.
Because you can get a top class degree in S.E. / C.S. and still not be able to handle a JVM OOM error.
It's also amusing how many people - my age or so - use Ubuntu as a daily driver these days that never went through the pain of configuring LILO or Broadcom drivers from source in Slackware ;)
I wouldn't recommend it for family or friends, but I'm happy with the trade off