-7 karma · joined May 14, 2020
It's not that big a deal IMO.
No need to lynch the guy over this.
This argument doesn't make sense in the context of remote work where the location of the individual has no bearing on the output capacity of the individual.
How does Facebook decide who deserves what salary? I thought it was entirely based on skill but clearly it is not.
It's possible to use two-phase commits instead. Two-phase commits can scale without limit but you have to be more careful when designing your tables and specifying your indexes.
For tables which need atomicity, you can add a 'state' column/field which is either 'pending' or 'settled'. You can have a separate parallel subroutine (or process) in your code to handle settlement. You have to design it in such a way that if the system fails at any point, it will re-process all 'pending' entries in an idempotent way.
It's a bit more work, but it scales without limit. You can add a shard key (or use account IDs) so that you can have multiple processes/hosts working in parallel to insert pending transactions and also multiple processes to settle them in parallel.
In financial transactions, I would separate it into two parts: A debit entry and a credit entry which are initially inserted into the DB as 'pending'. The settlement routine will match them up together - Making sure to process/settle the debit side of the transaction first and only once the debit is in the settled state, it will process/settle the credit side.
If the settlement engine sees any conflict (e.g. user tries to spend more money than they have by submitting many transactions in parallel), it will accept all the transactions as 'pending' but mark the later ones as canceled (they will not settle) so the credit entry will never be created on the other account.
My favorite DB is RethinkDB. It's a shame that the company behind it fizzled out and was absorbed by Stripe. I still cannot wrap my mind around why it's not more popular. It's similar to MongoDB but much better. It's the perfect database. It adds constraints which improve the quality of your code. Also RethinkDB scales very well and the control panel that comes with it is mind-bendingly powerful, I'm not kidding; you can click a button to shard or replicate a table over multiple hosts! WTF! I can't say the same about Postgres unfortunately. There is nothing truly remarkable about it.
I use Postgres for one of my projects today but purely because of compatibility reasons with an existing system. I don't understand what all the hype is with Postgres.
Also, universal standards are not necessarily a good thing. Decentralization with multiple competing tools and standards is good as it provides redundancy and opportunities for specialization.
If nobody is giving someone good feedback about their work, then it's impossible for them to feel like an impostor. There are many great developers out there who rarely get positive feedback about their work and they have no idea what people are talking about when they mention 'impostor syndrome'.
You'd be surprised by how many people fall through the cracks of the system; these people will never understand this idea of 'impostor syndrome'. I've been coding for over 15 years, both in my spare time and full time job. I've worked 7 days a week on open source. I've build several significant, scalable systems. In addition to my open source side projects, I've worked for at least a dozen different companies of all sizes in different industries and different countries.
The main theme of my career has been one of feeling constantly undervalued. I'm confident today precisely because I've been constantly undervalued in the past and this adverse environment has been the main driver for me to improve.
Recently, I started getting excellent feedback for my work, but it's not because I suddenly became a better developer, it's just that I changed companies too often to get noticed before and also I got very lucky that the people I work with now are smart enough to notice and have enough money in their pockets such that their opinions are taken seriously.
It has 2 steady income streams:
1. Monthly sponsorship donations.
2. Forging rewards from the Lisk blockchain. Those rewards are shared with the community.
SocketCluster powers Lisk's P2P network and protocol so on that basis I was voted into a forging position on the Lisk blockchain.
These two sources of income have been just enough to support myself and a couple of casual contributors. Took 7 years to get to this point.
Also, I occasionally did consulting in the past but that has not been reliable.
My experience makes me optimistic about blockchain tech's ability to help monetize open source projects. I'm particularly optimistic about the DPoS (Delegated Proof of Stake) mechanism because it allows big token holders to vote for open source project maintainers to be delegates on their blockchain and allows those open source maintainers to earn block rewards.
Forging on DPoS is like like Bitcoin mining, but a lot less hassle and requires no capital if you can get the votes. I'm working on the Lisk ecosystem now.
Helping others to monetize their open source projects in such a way that they can retain independence from corporate or government influence is my life's mission. My project is just a proof of concept.
BTW feel free to look for my email address on GitHub and get in touch with me if you want to participate somehow. I can't guarantee anything but I feel that the technology and incentives are improving - I'm working on a DEX ecosystem right now which should facilitate this.
I think maybe it has to do with:
1. Hype.
2. What percentage of developers were forced to use your tool/library against their will by their employers or forced upon them as a dependency of some other tool.
If a project is overhyped, then developers will be disappointed by reality and they will complain. The best you can do is try to set realistic expectations.
If a developer was forced to use your library by their employer (or it was forced upon them as a dependency of another tool/library that they're using and your dependency was throwing some weird error) then they will also complain. The best you can do about that is try to make your library work 'out of the box' as well as possible and make it work well in as many environments and operating systems as possible. Regulating hype by setting realistic expectations can also help prevent employers from forcing their developers to use a library. You should use more technical terminology instead of business buzz words when describing your project. You want to attract developers, not project managers.
That somehow it was all the result of the US Federal Reserve Bank's decade long policy of near 0% interest rates.
Based on how the world used to be, DHH would be absolutely right - But the world has changed. The financial system is an elaborate fraud and we must all find ways to accept it and navigate it.
My tech/programming blog has 1.4K subscribers and used to reliably get between 100 to 200 views per day, then in the space of 2 days from 6 March to 7 March this year it suddenly dropped down to around 10 to 20 views per day. The drop was extremely sudden and hasn't recovered since. Nothing changed on my side; I just started publishing more blockchain articles (since I work in that industry) but the drop badly affected my non-blockchain articles too (especially the ones which used to get a lot of recurring visitors from Google).
I wasn't relying on my blog financially though (just a hobby) so it hasn't hurt me too bad.
Here is my blog: https://medium.com/@jonathangrosdubois
Many of my past articles were related to my open source project (I've been maintaining it for many years and it is not blockchain related): https://socketcluster.io/
I feel that Google has always been working against open source software when it comes to search; maybe because their algorithm figured out that Google can't monetize open source projects (OSS projects don't tend to promote on Adwords). They tend to drive organic traffic mostly to paid SaaS solutions instead.
Strangely enough though, my open source project is now getting starred at a higher rate than ever before, it has almost 6K stars on GitHub and seems to be consistently getting several per week now even though I do no marketing and my Google organic traffic is terrible - The faster rate of stars is also strange because Google Analytics shows me flat traffic (has been around the same number of daily users for the past couple of years).
This is spot on. There are a lot of regulatory forces which help to prop up the stock market artificially. It's hard to imagine that pro-corporation regulations can go much further without severely damaging the underlying economy on which the stock market depends.
I think the drawbacks of bundling are still not worthwhile even for TypeScript, but I'm not surprised that people who liked CoffeeScript would like TypeScript even more. It is unquestionably more useful; at least you get some value in exchange for having to spend most of your development time waiting for the build to finish.
What is mind boggling to me is just how popular CoffeeScript became. It makes no sense at all. I guess it just got a lot of celebrity endorsements.
I think the problem is that 'real programmers' held such prejudiced and condescending views of JavaScript that they were not willing to learn it and figure out best practices. They were too proud for JavaScript but they still needed to use it for their job so that's why they were prepared to use any possible alternative; better or worse - At least their ego was protected.
Same thing with TypeScript; its main purpose is protecting developers' egos by allowing them to leverage the power of JavaScript without actually having to admit to themselves that they're using JavaScript.
IMO, it's self-deception. JavaScript has proven itself to be an amazingly flexible, adaptable and backward-compatible language. It has flaws just like any other language but it's an objectively amazing language. It has proven itself.
Some developers will insist that it was because of JS's monopoly on browsers that it was successful but you'd be surprised by how many set top boxes and car navigation systems are powered by JavaScript (and they could have used any other language).
JavaScript achieved this in spite of being constantly undermined - The fact that it was able to grow and dominate in such adverse social environment speaks to how truly great it is as a language.
The effects of tech monopolies are particularly obvious to those who work in open source.
For example, it's extremely common to find that some very expensive third-party services have free open source alternatives available - These open source communities are often struggling to stay alive. Big tech corporations hire thousands of engineers in-house and so it would cost them nothing extra to use the open source solution (they already have the engineering capacity to implement and manage it). But they won't! They will happily pay millions of dollars of fees annually to get something that they could have gotten for free and maybe paid an optional $20K per year 'tech support' fee to the open source community. Not only that, but their system would be way more flexible because the corporation would have full control over the open source code and their own data. For example, the $400 million that Facebook spent on acquiring Giphy could have been saved if they had used an open source solution instead. Heck, they could have built Giphy themselves from the ground up in a couple of months using open source solutions for very little additional engineering cost.
Corporations have no incentives to be efficient; instead they will use some expensive provider because the CEOs of both companies are friends. They have a monopoly so they can afford to be very wasteful.
Economists are quick to point out that the new money which is created of of thin air is not given outright, but rather, it is loaned out - Therefore, by virtue of having to pay it back, corporations do not have an unfair advantage.
I disagree with this conclusion because an entity's access to loans is based almost entirely on how much collateral they possess - This necessarily implies that those entities which have more capital are able to take out bigger loans and thus derive more profits from these loans.
For example, if you have $100K in a particular asset (e.g. stocks), you can use that as collateral to borrow an additional $100K and you end up controlling $200K worth of assets in total. So if the yield on those assets is 10% per year, you will end up getting 20% per year relative to your own capital. 20% of $100K is $20K.
So according to this principle, a company which has $100 million in assets can borrow an additional $100 million - This means that an asset class which can generate 10% yield can be bought on leverage to generate 20% yield on the initial capital. 20% of $100 million is $20 million. This means that $10 million of that profit was derived entirely from credit which was printed out of thin air by banks. That $10 million is free money and was given solely on the basis of existing capital.
This is why the rich get richer; it has nothing to do with value creation. Whenever banks print money out of thin air and inject it into the economy, everyone in the country who receives a salary in that currency ends up paying for that equally because of dilution in the value of their salaries. In effect, this means that, salary earners and small capital owners are subsidizing big capital owners. This is what is fundamentally unfair about our financial system and why big corporations have to be limited; they're not successful because they're efficient, they're successful because they own more capital than everyone else and can thus access most of the newly 'printed' fiat money.
1. 'F1' which represents any possible function which does not invoke the H(F1) function internally.
2. 'F2' which represents any possible function which invokes the H(F2) function internally.
Turing's proof relies entirely on the existence of 'F2' functions and the fact that these kinds of functions always lead to a an infinite loop deadlock condition. Turing's proof relies on these 'F2' functions as a counter example to prove why H cannot exist. Turing's proof does not apply for functions of the 'F1' kind.
So my thinking is that assuming that there existed a probabilistic analyzer function `H` which worked with 'F1' functions and which could be modified to also work with 'F2' functions (I.e. by adding a probabilistic error % as I suggested), then that would invalidate Turing's counter-example. It would not give any answers about the halting problem itself though; just move the problem back to a state of uncertainty.
My idea aims to prove that if you have an 'H' which works for 'F1' then it can be easily modified to also work for 'F2' if you're prepared to accept an error probability each time you run the function.
A key part of my argument is that any F2 function can use an error % as an escape hatch to protect itself from infinite recursion and thus gives those functions the ability to decide their own output.
For these kinds of F2 functions, whatever output H(F2) returns becomes self-fulfilling after the recursion has finished unwinding and so it does not matter if H(F2) is true or false.
My idea was that what if the halting detection function sometimes intentionally lied about whether or not the program halts (E.g. just returned a random true/false 1% the time instead of actually doing the analysis work) then because Turing's proof is recursive (and relies on the occurrence of an infinite recursive deadlock condition), eventually, at a certain random depth in the recursion, the halting detection function would break out of the recursion when it hits that random error case. So the intentional % error added to the halting detection function would prevent hitting the infinite recursion case on which Turing's proof relies. The downside of this approach would be that my hypothetical halting detection function would return incorrect results a certain percentage of the time when applied to other algorithms; but this problem can be offset by running it multiple times against the same input. The accuracy of such a function could approach 100% as you run it more often but never quite reach 100%.
This is a very optimistic proposition. I think they might never get there. Based on what I read so far, I have concerns that the final solution will be too complex, brittle and vulnerable.
1. They will launch.
2. They will find out that Ethereum doesn't scale.
3. They will move to an off-chain solution.
On the plus side, the extra demand generated by Reddit will boost Ethereum transaction fees to insane levels which is going to make the Ethereum price go up (because higher fees = more lucrative mining). Then the Ethereum/Reddit insiders who organized this elaborate corporate scam are going to cash out.
I can't believe how quickly people forgot about CryptoKitties. Surely Reddit developers know about Ethereum's limits.
It seems that we have entered into a new economic era. It's called "Let's use cryptocurrency as a way to collaboratively fool our corporate employers for personal profit".
1. Find a big corporation whose managers are naive enough to agree to participate in some hyped up and non-scalable blockchain project.
2. Convince your managers to start such a project and do it in such a way that this project is going to boost demand for cryptocurrency X.
3. Employees buy cryptocurrency X.
4. Project launches, cryptocurrency X struggles to handle the load and as a result, transaction fees skyrocket, sharply driving up the token price.
5. Employees sell their cryptocurrency X at the peak.
6. Users complain about high fees. Employer realizes that this is not going to work and abandons the project.
7. Price crashes back to what it was before. Corporate employees are pleased with their profits. Corporation has no clue that they've just been scammed by their own employees. End users of the service who had to actually pay for the transaction fees paid for most of the cost.
Companies should be launching their own blockchains, not ERC-20 tokens; that only benefits Ethereum.
The people who built React didn't understand the concept of 'over-engineering'... That's why they started integrating with Babel, WebPack etc...
Babel often introduces hundreds or even thousands of dependencies into projects, but what does it actually do for the end user of the software? Absolutely nothing! If you use VueJS without WebPack, you can get the same results with only a handful of dependencies and your project code will be cleaner and more stable too.
I feel the same way about TypeScript. Ok it gives you type safety, that's great, but it turns your project into a vulnerable and non-portable mess. Suddenly you have hundreds of dependencies that do nothing for the user, you now need to wait for builds every time you change anything in your code, you get build artifacts like source maps and definition files everywhere, you encounter issues with wrong line numbers when debugging because your environment doesn't know where to find or how to interpret the source maps. ...and now you have to make sure that your project code is not only compatible with all developers' Node.js versions, but that it's also compatible with their TypeScript compilers because TypeScript keeps changing all the time and also TS configs are constantly added and removed.
It's complete madness. Good article.