Ironically, I had to locate the X and close two video ad overlays in order to calm the screen enough to enjoy the article. And even then, the right part of my screen was flashing ads, and every few paragraphs an ad was shoehorned into the text.
And yeah, don't have adblock on my work PC which is probably why it's so insufferable.
Advertising the kind of industry that you'd really like to shove into a plywood submarine and set its bearings for the Titanic.
When I was a young kid in the early 1980s, my grandpa had a large book about Darwin's voyages and the Theory of Evolution. The book probably dated from the 1950s or 1960s and contained countless photos of fascinating creatures, reproduced with all the printing technology of the era.
Whenever we visited him, I would flip through the book and marvel at the creativity of nature.
These photos made me feel a little bit in the same way.
Tried it out on some REST response from a local test server.
And, well, as much as I applaud the effort, I also think that I'll stick to my text editor for browsing JSON data and to jq for extracting data from it.
My text editor because it's easy to perfom free text search and to fold sections, and that's all that I need to get an overview.
Jq because it's such a brilliantly sharp knife for carving out the exact data that out want. Say I had to iterate a JSON array of company departments, each with a nested array of employees, and collect everyone's email. A navigational tool doesn't help a whole lot but it's a jq one liner. Jq scales to large data structures in a way that no navigational tool would ever do.
Also, there is the security issue of pasting potentially sensitive data into a website.
> Cryptocurrencies were meant to put an end to such things
Yeah, well, Communism was meant to put an end to poverty and class injustice. Brexit was meant to restore glory to Britain. The Catholic Church was mean to put an end to vice. Things don't always do what they say on the tin.
As the Bible puts it: "For every tree is known by its own fruit".
Specifically, if the fruit seems consist of nothing but speculative bubbles and billion dollar frauds then that may be the true nature of the tree.
Did a my first paid software development pretty much exactly 30 years ago, specifically I was hired to port a word processor from the Amiga to the Commodore 64. So my experience is mostly related to the word of 8-bit home computers, already a dying world by then, and I wouldn't be able to tell how working in an office was like as a was still in school at the time and it was a side project.
Still, a few general observations about that particular corner and that particular time of software development:
- There were multiple successful 8-bit platforms, all of which were very different from each other. Different makes of CPU, different custom chips, different memory layout. You could be an expert in one and an absolute novice in others.
- The platforms were more constrained, by magnitudes. A very limited color palette, far fewer pixels, far less RAM, and far slower CPUs. For a semi-large project, it could even become a challenge to keep the source code in memory and still have room for the compiled machine code.
- On the upside, the platforms were also far more stable and predictable. A Commodore 64 that rolled out from the factory in 1982 would behave identically to one built five years later. Every C64 (at least on the same continent) would run code in exactly the same way.
One thing that followed from the scarcity and from the stability is there was an incentive to really get close to the metal, program in assembly language, and to get to know the quirks and tricks of the hardware. Fine tuning an tight loop of assembly code was a pleasure and one could not simply fall back on Moore's law.
It was a simpler world in the sense that you didn't have to check your code on a number of machines or your UI on a number of window sizes. If it worked on your machine, it could be assumed to work everywhere else.
Another thing that I remember is that there was more friction to obtaining information. The internet wasn't a thing yet but there were text files flowing around, copied from floppy to floppy, and you could order physical books from the library. But a lot of learning was just opening up other people's code in a mchine code monitor and trying to understand it.
Some of these things started to change with the Amiga platform, and once PCs took over it was another world, with a plethora of sound cards and graphics cards and different CPU speeds that people had to deal with.
In all fairness, I don’t think “crypto” should be banned as such. Partly because it’s a loose and descriptive term, unlike asbestos, which is well defined and tangible. So a blanket ban wouldn’t work.
And also because it’s not necessary; existing regulation will get us most of the way:
- if you are, in effect, selling a security, let this be regulated this like any other security
- if you are, in effect, running a bank, etc.
- if your coin X acts like an intermediary for transferring money to hostile jurisdiction Y, then regulate transfers to X like transfers to Y. Forbid these if necessary.
- if your manufacturing process is needlessly wasteful then forbid this manufacturing process (globally) under threat of forbidding your product
I brought it up because it’s close to Buenos Aires and because I’m under the impression that Uruguay is a pretty well run place. I’m assuming there to already be a lot of connections, personal and trade, between the two metro areas. I’ve never been to either and anything beyond geography is guesswork on my part. Anyway, thanks for the clarifications :)
Asbestos solved an actual problem, as did freon. Both also created larger problems and were eventually banned. We could have given them some more time, I guess. Maybe, if given another fifty years, the freon industry might have (waves hands) fixed its issues with the ozone layer. Or maybe not. That wasn’t the trajectory, anyway.
Back in 2022, we’re now looking at a technology that has not, for all its promises of a glorious future, has not produced anything but centralized Ponzi-as-a-Service platforms, a way for organized crime to move money, and smokestacks. At least asbestos and freon had some utility.
If you need to cross a border to fetch your hard currency (or equivalent amount of goods) then what is the value add of using crypto compared to, say, opening a bank account in Montevideo and making a bank transfer?
Sure, index funds are freeloading a bit in the sense that they don't allocate any resources to scrutinizing the prospecta of each individual company, they just assume that other market players have done they homework.
This would be a problem if every investment was passively managed but that's not the case and it will never be. If we ever came close to that, then actively managed funds would outperform the passively managed ones by large margins.
Skimmed most of it but still learned some useful stuff. Will keep it in my bookmarks.
Also, would suggest mentioning gitbash in the Windows section. You get it for free with git so it's easy to come by, even in corporate environments where obtaining permission to install software is hard. If combined with something like ConEmu, it's actually pretty nice.
I'm currently experimenting with migrating a side project to now 2.0. It has been a learning experience, for sure. But so far I think that it has been time well spent.
My overarching goal is to be able to create and deploy a new web app, from scratch, and just have the platform take care of all the boring stuff that should just work.
So far I've been pretty pleased with nextjs and now 2.0, especially once I grokked the lambda concept and found out how to slice my old express server into vertical pieces. Also, I had to realize that the monorepo model was the right fit.
I'm not quite up and running yet on now 2.0 but I'll be any day now. Curious as to how it will affect my bill.
At one time I was contracting at a place where every process was broken, from IT to management to testing. It wasn't really a place that attracted talented developers. There were a some developers that were talented and a lot which were mediocre or had given up along the way. Development progressed at the pace of syrup. They paid on time, though.
Anyway, being a professional, I put in my hours and did my best to contribute until the contract ran out. But I also stuck a post-it note to the bottom of my screen with my all-time favourite Polish phrase: "Nie mój cyrk, nie moje małpy". Literally: "Not my circus, not my monkeys.". I.e. the inherent brokenness wasn't my problem to fix.
In my experience, not having German as my first language, you can get pretty far with guesses and rules of thumb as far as the genders are concerned. With experience your guesses will become more educated. You will start to feel the patterns in how the ending of a word maps to the gender of the noun, with some accuracy. You'll memorize some of the most common exceptions. "Impossible" delineations such as "mit das [..]" will feel wrong.
Also, by all means, memorize the delineation tables and the rotes that will help you identify accusative and dative. I still remember those from school and they never cease to be useful.
Oh, and by the way, it turns out that Polish is even worse in terms of grammar .. or maybe my mind is just less pliable these days :)
A spaghetti monster which solves a real business problem can be improved, chunked into pieces, gradually rewritten, whatever improves maintenance. If need be, there will be funds and time for doing so.
By contract, an impeccably architectured, layered, no-design-patterns-omitted, product which solves no business problem .. oh, the horror.
Here in .dk-land we have several Blue Apron style businesses.
The most prominent one started out more than two decades ago by as a kind of subscription service -- every week you'd get a bag containing the produce of the season, along with weird stuff like Hokkaido pumpkins that most people had no idea what to do with.
These days they ship recipes along with the exact quantities of ingredients that you'll need for cooking. Often ingredients that are hard to come by in grocery stores. It's time saving and usually delicious.
Anyway, my point is, they bootstrapped their business, pivoted a bit here and there, and built it to be profitable. So it's certainly doable.
- Usually, for large chunks of work, you want to bring in more people. Both because they tend to involve several modules or several layers of the stack, and very few people are equally skilled in every part of the codebase. But also because there will most probably be design decisions and tradeoffs along the way to discuss. Coordinate who is working on which parts of the codebase at any given time.
- I'd avoid excessive preplanning. But I'd make tasks to make explicit the general plan and the interdependencies. E.g. create new server API, then refactor client, then remove old server API.
- Don't be too concerned with showing progress in stand-ups. Feeling like you need to do this to justify yourself is a team process smell. Abandon them if they bring no value, e.g. if you have a de facto three people subteam who is coordinating all the time anyway.
I don't think a developer is ever "easily replacable" (discounting obviously incompetent people which shouldn't have been hired in the first place). As soon as we join a team we start accumulating all kinds of knowledge about the codebase, the domain, the history, company politics, etc. Replacing with a new hire is back to square one. It's expensive, disturbing, and generally undesirable from a company perspective.
Yet you can't blame companies for trying to make each developer "as replacable as possible". There is always an employee churn -- people leaving for all kinds of reasons, some after a short while, some after decades -- and new people being hired. It's in the company's best interest to minimize the cost of this entirely predictable churn.
Actually, I think it's in the best interest of the developer as well. The more replacable we can make ourselves, the easier it is to leave to work on new, exciting projects. The more irreplacable, the more likely we are to be the dude who spent the past ten years maintaining the module written in $OBSOLETE_LANGUAGE_OR_FRAMEWORK because everyone else left and nothing was really documented.
I don't think daily stand-ups is really the tool for making yourself replacable since the information transmitted tends to be very short lived. Good code structure, well maintained tests, rock solid build env, good documentation of purpose, requirements, design considerations ... we never quite arrive at that nirvana but it would be the goal to aim for.
> If the market price of gold increases, the production of it will increase (though to a lesser degree of other commodities).
Yet the total amount of gold on this planet is finite, and as the millennia have passed, it has become increasingly expensive to dig it out of the ground. These are the same properties that people laud in bitcoin.
> Bitcoin's supply curve is programmed with time as the only input
As far as I am informed, bitcoin mining farms also tend to be connected to the power grid. May be just to keep the soft drink vending machine running. Dunno.
> This is a coup de grâce against every other existing store of value.
Limited supply is by no means unique to bitcoin. Gold and real estate share the same properties.
And yeah, don't have adblock on my work PC which is probably why it's so insufferable.
Advertising the kind of industry that you'd really like to shove into a plywood submarine and set its bearings for the Titanic.