I’m wondering why is “Zero to One” such a widely used term these days, and yet its counterpart, one to zero, is hardly discussed.
I want zero extra actions to have to be performed so that:
• the tests are run,
• the code deploys,
• the schema is respected,
• the paycheck is sent,
• the event is in my calendar, with the proper link to join the meeting,
• access permissions are granted upon being asked for, and
• non-engineers are not messing with well-functioning engineering processes.
Each of the above billet points by itself deserves a good book.
I want zero extra actions to have to be performed so that:
• the tests are run,
• the code deploys,
• the schema is respected,
• the paycheck is sent,
• the event is in my calendar, with the proper link to join the meeting,
• access permissions are granted upon being asked for, and
• non-engineers are not messing with well-functioning engineering processes.
Each of the above billet points by itself deserves a good book.
The pros and cons of starting a company.
Via Spencer Greenberg.
1. Autonomy
Pro: you're the boss and decide what to do.
Con: you HAVE to always decide what to do. There will be a huge array of options at any given moment, and you'll never know for sure which to work on. You can seek advice, but ultimately YOU are the one who must decide.
2. Lifestyle
Pro: since you're the boss, you'll have flexibility in your hours.
Cons: you'll inevitably be working a lot of hours. It takes a lot of work to succeed as an entrepreneur.
3. Resilience
Pro: it's an incredible way to train resilience, persistence, and problem-solving skills.
Con: the world will punch you in the face between 5 and 100 times, and if you ever give up, you lose. This is stressful, and most humans would give up after 5 or 10 face punches.
4. Expected Value
Pro: if you're well suited to it and work on a good idea, the expected (mean) value in terms of potential impact and monetary reward can be REALLY high. Some companies have truly altered the course of history.
Con: the probability of failure is high, and luck is a significant factor. And unless you have substantial savings, you'll likely be living frugally at first.
5. Learning
Pro: you will learn a tremendous amount. Even if the startup doesn't work out, this valuable experience will apply to MANY other things. I don't know of another way to learn so many things so quickly.
Con: you will inevitably make many mistakes (ouch), and you have to face up to them (double ouch) in order to learn fast enough. It forces you to acknowledge and improve (or develop workarounds for) your weaknesses.
6. Meaning
Pro: you can choose to work on an idea that is DEEPLY meaningful to you. Most jobs don't provide this level of meaning.
Con: if you fail, you will have invested a lot of time in (and then failed at) something deeply meaningful to you.
7. Respect
Pro: many people have a lot of respect for entrepreneurs, and it's considered cool in plenty of circles.
Con: this respect increasingly kicks in as success increases, and before that, some people won't even respect it as a career choice.
8. Relationships
Pro: you will likely meet lots of interesting people and build meaningful relationships with your team members.
Cons: you may have to deal with difficult personalities or navigate complex human dynamics when it comes to employees, investors, and/or co-founders.
9. Responsibility
Pro: it teaches you a deep form of responsibility, which strengthens your character.
Con: you are ultimately, at the end of the day, responsible for everything. You're the captain, the last line of defense, and the goalie.
10. Adaptability
Pro: it hones your creativity and adaptability, and can really build self-confidence and help you develop a sense of how much you're capable of (probably more than you think!), as you figure out solutions for complex challenges, develop new ideas, and map out how to make them a reality. It pushes your boundaries in new ways and makes you grow.
Con: it can stretch your creativity and adaptability to the limit. Plans, essential as they are to make, rarely survive their collision with reality. It sometimes pushes your boundaries more than you would like.
So, why NOT be an entrepreneur? Because it's a high risk, chaotic, stressful, responsibility filled, boundary-pushing, challenging life. And it's hard work.
Not everyone is suited to this path, and it's irresponsible to pretend that everyone is.
BUT, if you're well suited for it, it can be one of the most deeply meaningful, high value, high impact lives to lead. You'll meet lots of people, build resilience and adaptability, push your skills to new heights, and learn a STAGGERING amount.
For some people, it is absolutely their best life path.
You can learn more and get in touch with us at: https://www.sparkwave.tech
Source: https://www.facebook.com/spencer.greenberg/posts/10105424972822772
Via Spencer Greenberg.
1. Autonomy
Pro: you're the boss and decide what to do.
Con: you HAVE to always decide what to do. There will be a huge array of options at any given moment, and you'll never know for sure which to work on. You can seek advice, but ultimately YOU are the one who must decide.
2. Lifestyle
Pro: since you're the boss, you'll have flexibility in your hours.
Cons: you'll inevitably be working a lot of hours. It takes a lot of work to succeed as an entrepreneur.
3. Resilience
Pro: it's an incredible way to train resilience, persistence, and problem-solving skills.
Con: the world will punch you in the face between 5 and 100 times, and if you ever give up, you lose. This is stressful, and most humans would give up after 5 or 10 face punches.
4. Expected Value
Pro: if you're well suited to it and work on a good idea, the expected (mean) value in terms of potential impact and monetary reward can be REALLY high. Some companies have truly altered the course of history.
Con: the probability of failure is high, and luck is a significant factor. And unless you have substantial savings, you'll likely be living frugally at first.
5. Learning
Pro: you will learn a tremendous amount. Even if the startup doesn't work out, this valuable experience will apply to MANY other things. I don't know of another way to learn so many things so quickly.
Con: you will inevitably make many mistakes (ouch), and you have to face up to them (double ouch) in order to learn fast enough. It forces you to acknowledge and improve (or develop workarounds for) your weaknesses.
6. Meaning
Pro: you can choose to work on an idea that is DEEPLY meaningful to you. Most jobs don't provide this level of meaning.
Con: if you fail, you will have invested a lot of time in (and then failed at) something deeply meaningful to you.
7. Respect
Pro: many people have a lot of respect for entrepreneurs, and it's considered cool in plenty of circles.
Con: this respect increasingly kicks in as success increases, and before that, some people won't even respect it as a career choice.
8. Relationships
Pro: you will likely meet lots of interesting people and build meaningful relationships with your team members.
Cons: you may have to deal with difficult personalities or navigate complex human dynamics when it comes to employees, investors, and/or co-founders.
9. Responsibility
Pro: it teaches you a deep form of responsibility, which strengthens your character.
Con: you are ultimately, at the end of the day, responsible for everything. You're the captain, the last line of defense, and the goalie.
10. Adaptability
Pro: it hones your creativity and adaptability, and can really build self-confidence and help you develop a sense of how much you're capable of (probably more than you think!), as you figure out solutions for complex challenges, develop new ideas, and map out how to make them a reality. It pushes your boundaries in new ways and makes you grow.
Con: it can stretch your creativity and adaptability to the limit. Plans, essential as they are to make, rarely survive their collision with reality. It sometimes pushes your boundaries more than you would like.
So, why NOT be an entrepreneur? Because it's a high risk, chaotic, stressful, responsibility filled, boundary-pushing, challenging life. And it's hard work.
Not everyone is suited to this path, and it's irresponsible to pretend that everyone is.
BUT, if you're well suited for it, it can be one of the most deeply meaningful, high value, high impact lives to lead. You'll meet lots of people, build resilience and adaptability, push your skills to new heights, and learn a STAGGERING amount.
For some people, it is absolutely their best life path.
You can learn more and get in touch with us at: https://www.sparkwave.tech
Source: https://www.facebook.com/spencer.greenberg/posts/10105424972822772
X (formerly Twitter)
Spencer Greenberg 🔍 (@SpencrGreenberg) on X
A mathematician/entrepreneur in social science. Tweets about psychology, society, rationality, tech, science, and philosophy. Founder of https://t.co/2YGraOwo77
From a work chat:
— What is data warehouse? Is it a database?
— [ me explaining what MapReduce, Hadoop, HiveQL, Spark, etc. are ]
— Oh, I got it. Mongo can do it, right?
I'm conflicted between thinking whether it's our folks got something very wrong, or the Mongo folks got something very right.
Full disclosure: Religiously, I'm inclined to believe it's the former. Mongo hasn't done much right, to be honest, not to mention their marketing and product placement is misleading to say the least.
But the very fact that in 2020 the new generation tends to view the world of big data from an entirely different point is certainly something to ponder on.
— What is data warehouse? Is it a database?
— [ me explaining what MapReduce, Hadoop, HiveQL, Spark, etc. are ]
— Oh, I got it. Mongo can do it, right?
I'm conflicted between thinking whether it's our folks got something very wrong, or the Mongo folks got something very right.
Full disclosure: Religiously, I'm inclined to believe it's the former. Mongo hasn't done much right, to be honest, not to mention their marketing and product placement is misleading to say the least.
But the very fact that in 2020 the new generation tends to view the world of big data from an entirely different point is certainly something to ponder on.
How can programmers keep track of their design decisions?
Let me open up by quoting an okay joke from memory:
If you change random things in your code until it works it’s “bad debugging”, but if you can do it several thousand times a second it is called machine learning and pays three times what you are making now.
One way to understand this joke is to appreciate the power of the simple idea that in the right environment, that embraces natural selection, a bunch of well-tested heuristics generally do the job quite well.
If the above does not look anywhere near the answer you are looking for, kindly allow me to rephrase it in the following way:
• Design decisions are what shapes the implementation in code.
• Good design decisions are the ones that yield implementations that last.
• People with good design decisions get to make more of them later on.
Still not looks like an answer? Okay, let me set the record straight.
It’s not that programmers contemplate a lot on which design decision to make, then make this decision, and then adhere to it. The real world works pretty much the other way:
• The process of settling on a design decision involves multiple proposals and multiple arguments pro and against them.
• Throughout making the design decision, the proposals that were countered successfully are eliminated, with all the arguments against remembered by everyone involved.
• Ultimately, one proposal remains, and is being executed upon. If multiple competing proposals make it to the final round, an authoritative decision is generally being made, with people not agreeing with this decision often times leaving the team or the project or the company.
• It is at this point, when the decision is largely made, optionally, the design doc is written. It may well share some 90% of the contents with what it was during the proposals phase, but, generally, when the design doc is being finalized, the decision has been already made, and, often times, the work has already started.
Now, I hope, the above paints a clear picture that does constitute the answer to the original question.
Software engineers (a.k.a. programmers) don’t really keep track of their design decisions. They don’t have to, because given the information they have obtained during all the discussions before the decision was made, they would make the same decision right away in an eyeblink.
And someone with a strong opinion against the decision that hasn’t been made has either already changed teams, or remembers very well what exactly was the decision they disagreed with, and yet chose to stay on the team despite.
The beauty of engineering, and, especially, software engineering, is that the designs tend to get battle-tested. There’s a real-life feedback look. There’s Skin in the Game, to quote Nassim Taleb.
Software engineering, generally speaking, is no peace-time policymaking game, where arguments are about as strong as they sound to be. Software engineering is closer to a series of war-time campaigns, with the enemy being the laws of nature, systems complexity, and the strength and the dynamics of the team working to implement and later support the designs based the decisions made.
So, most of the time, there’s really no need to keep track of design decisions. What works a lot better is to surround oneself with experienced people who can readily provide plenty of arguments that both stick to everyone’s mind right away, and explain beyond reasonable doubt which decision is and remains the best one given the constraints.
Let me open up by quoting an okay joke from memory:
If you change random things in your code until it works it’s “bad debugging”, but if you can do it several thousand times a second it is called machine learning and pays three times what you are making now.
One way to understand this joke is to appreciate the power of the simple idea that in the right environment, that embraces natural selection, a bunch of well-tested heuristics generally do the job quite well.
If the above does not look anywhere near the answer you are looking for, kindly allow me to rephrase it in the following way:
• Design decisions are what shapes the implementation in code.
• Good design decisions are the ones that yield implementations that last.
• People with good design decisions get to make more of them later on.
Still not looks like an answer? Okay, let me set the record straight.
It’s not that programmers contemplate a lot on which design decision to make, then make this decision, and then adhere to it. The real world works pretty much the other way:
• The process of settling on a design decision involves multiple proposals and multiple arguments pro and against them.
• Throughout making the design decision, the proposals that were countered successfully are eliminated, with all the arguments against remembered by everyone involved.
• Ultimately, one proposal remains, and is being executed upon. If multiple competing proposals make it to the final round, an authoritative decision is generally being made, with people not agreeing with this decision often times leaving the team or the project or the company.
• It is at this point, when the decision is largely made, optionally, the design doc is written. It may well share some 90% of the contents with what it was during the proposals phase, but, generally, when the design doc is being finalized, the decision has been already made, and, often times, the work has already started.
Now, I hope, the above paints a clear picture that does constitute the answer to the original question.
Software engineers (a.k.a. programmers) don’t really keep track of their design decisions. They don’t have to, because given the information they have obtained during all the discussions before the decision was made, they would make the same decision right away in an eyeblink.
And someone with a strong opinion against the decision that hasn’t been made has either already changed teams, or remembers very well what exactly was the decision they disagreed with, and yet chose to stay on the team despite.
The beauty of engineering, and, especially, software engineering, is that the designs tend to get battle-tested. There’s a real-life feedback look. There’s Skin in the Game, to quote Nassim Taleb.
Software engineering, generally speaking, is no peace-time policymaking game, where arguments are about as strong as they sound to be. Software engineering is closer to a series of war-time campaigns, with the enemy being the laws of nature, systems complexity, and the strength and the dynamics of the team working to implement and later support the designs based the decisions made.
So, most of the time, there’s really no need to keep track of design decisions. What works a lot better is to surround oneself with experienced people who can readily provide plenty of arguments that both stick to everyone’s mind right away, and explain beyond reasonable doubt which decision is and remains the best one given the constraints.
"Read the last line of a huge text file" is my new favorite coding task for those who self-identify as system programmers in Python.
Our first system design meetup video is now up.
I enjoy interviewing, and enjoy helping people prepare for interviews. This year I realized the system design format is taking off, and I especially like conducting interviews of that kind. At the same time it appears there's not much quality content available online, so, without further due, we recorded this piece and are presenting it to you.
Kudos to Tilek Mamutov and the Outtalent.com team for helping to make it happen.
The format is similar to the practice sessions we ran before, with a few tweaks to make it more relaxed. It still is an experiment, to the degree that I haven't even wrapped my head around whether it should be called a session, a colloquium, or a meetup. Let me leave it for you guys to judge, and hope you like it.
I plan on making this a regular thing, and if you want to join one of the next ones, here's a form for us to pick the best date and time.
I enjoy interviewing, and enjoy helping people prepare for interviews. This year I realized the system design format is taking off, and I especially like conducting interviews of that kind. At the same time it appears there's not much quality content available online, so, without further due, we recorded this piece and are presenting it to you.
Kudos to Tilek Mamutov and the Outtalent.com team for helping to make it happen.
The format is similar to the practice sessions we ran before, with a few tweaks to make it more relaxed. It still is an experiment, to the degree that I haven't even wrapped my head around whether it should be called a session, a colloquium, or a meetup. Let me leave it for you guys to judge, and hope you like it.
I plan on making this a regular thing, and if you want to join one of the next ones, here's a form for us to pick the best date and time.
YouTube
System Design Meetup 2020-Nov-28: Yelp / geospatial sharding
This is the first system design video that we are releasing.
I'm Dima Korolev, I enjoy mentoring, teaching, and interviewing people, and I do it frequently. The thought of hosting a public session on system design has crossed my mind a while ago, and today…
I'm Dima Korolev, I enjoy mentoring, teaching, and interviewing people, and I do it frequently. The thought of hosting a public session on system design has crossed my mind a while ago, and today…
Thanks for all the interest to the previous post!
I've put together a Slack "workplace" (here's an invite link to it), and a Twitter handle. We are planning to host the next event this coming Friday or Saturday.
I also did some magic with the "connected discussions account" here on Telegram, so, if we're lucky, from this post on there'll be comments enabled here.
I've put together a Slack "workplace" (here's an invite link to it), and a Twitter handle. We are planning to host the next event this coming Friday or Saturday.
I also did some magic with the "connected discussions account" here on Telegram, so, if we're lucky, from this post on there'll be comments enabled here.
Next meetup video: Designing user authentication as if it's 1998 (spoiler: not really 1998).
I've enjoyed it quite a bit — thanks everyone who joined and helped! — and am looking forward to the next ones.
As a friendly reminder, here's our Slack, and here's an invite link to it.
I've enjoyed it quite a bit — thanks everyone who joined and helped! — and am looking forward to the next ones.
As a friendly reminder, here's our Slack, and here's an invite link to it.
YouTube
System Design Meetup 2020-Dec-05: Design Auth
Today we are talking authentication.
A very valuable 16 minutes piece. Kahneman talks about intuition and how to use it effectively, as well as about the role of optimism, both for an individual and for our society as a whole.
YouTube
Prof. Daniel Kahneman: Art & Science of Decision Making
In an insightful Q&A, the renowned Nobel Prize Laureate in Economics and best-selling author reveals what drives our choices in business, science, and life.
DANIEL KAHNEMAN, Behavioral Economist and Nobel Laureate
ALEC ELLISON, Founder, Outvest Capital, former…
DANIEL KAHNEMAN, Behavioral Economist and Nobel Laureate
ALEC ELLISON, Founder, Outvest Capital, former…
Web Crawler: today's #meetup video.
With interesting detours into message queues and brokers, as well as into whether Redis can be used as a queue, and if FIFO is that important when it comes to managing the crawl queue.
(Let me know if you'd rather not have me post these links in this channel, still calibrating on this social media thingy. Thanks!)
With interesting detours into message queues and brokers, as well as into whether Redis can be used as a queue, and if FIFO is that important when it comes to managing the crawl queue.
(Let me know if you'd rather not have me post these links in this channel, still calibrating on this social media thingy. Thanks!)
YouTube
System Design Meetup 2020-Dec-12: Web Crawler
Today we are having a conversation about how to build a Web crawler. The Kafka / Redis part, about sharding and persistence, was particularly interesting to my taste.
Join us on Slack: https://join.slack.com/t/newworkspace-doa3816/shared_invite/zt-jp0n1w6c…
Join us on Slack: https://join.slack.com/t/newworkspace-doa3816/shared_invite/zt-jp0n1w6c…
Today's meetup: A distributed filesystem and much more.
YouTube
System Design Meetup 2020-Dec-19: Distributed Filesystem
At risk of spoiling some of the fun we talked about using the torrent protocol, leveraging distributed consensus / lock filesystems, and ultimately designing a large-scale key-value store, which can be a prototype of Cassandra or of GFS depending on how you…
And our next system design meetup video: designing WhatsApp / Telegram / FB Messenger.
With online whiteboards this time, hope you enjoy it! We had a lot of fun for sure, and, as always, we've learned something too.
As a fly in the ointment, my Ubuntu screen recording at 60FPS stared dropping frames, effectively freezing the video in the last quarter or so of the recording. The audio is fine. Lesson learned, I hope to do better next time.
With online whiteboards this time, hope you enjoy it! We had a lot of fun for sure, and, as always, we've learned something too.
As a fly in the ointment, my Ubuntu screen recording at 60FPS stared dropping frames, effectively freezing the video in the last quarter or so of the recording. The audio is fine. Lesson learned, I hope to do better next time.
YouTube
System Design Meetup 2021-Jan-14: Messenger
We are designing WhatsApp / Telegram / FB Messenger, and this also is the first meetup where we use online whiteboarding.
And yesterday at the meetup we talked about reactive streaming.
I'm experimenting with formats tirelessly =) and this one was not really about discussing the design of a particular large-scale system, but more of a casual conversation on one of the important topics in modern software architecture.
I'm experimenting with formats tirelessly =) and this one was not really about discussing the design of a particular large-scale system, but more of a casual conversation on one of the important topics in modern software architecture.
YouTube
System Design Meetup 2021-Jan-23: Reactive Streaming
Victor has been kind enough to lead the conversation about reactive streaming.
1:13 Victor introduces reactive streaming.
2:24 Stream & state transitions as opposed to RPCs.
3:54 Frontend and other applications.
5:27 Reactive streaming is a mindset, not…
1:13 Victor introduces reactive streaming.
2:24 Stream & state transitions as opposed to RPCs.
3:54 Frontend and other applications.
5:27 Reactive streaming is a mindset, not…
New meetup video: friends & content suggestions. Two of us present two designs, one mostly based on graph traversal / hardcore CS, and the other one mostly based on embeddings / real-time ML.
YouTube
System Design Meetup 2021-Feb-27: Friends & Content Suggestions
We present two possible designs of "people you may know" or "content you may be interested in": the CS one based on graph traversal and the ML one based on embeddings.
I am cautiously optimistic for the world where the reopening does happen, but quite a few people still enjoy working from home.
This would give those of us who are both tech-people and people-people a tremendous opportunity: to live and work literally anywhere, and have business trips of a few days to ~1.5 weeks long once or twice a month.
With all my dislike of the modern corporate structure, if most of my team is remote, we gather often via video chats, and yet some ~half of us enjoy to see each other in person, which we do by gathering in various places for mini-offsites on the company's buck, as the company clearly understands the cost-effectiveness of such an approach ...
... that's the world I might enjoy living in.
~ ~ ~
Although it's all a distant dream so far. As of today, most places can't even be traveled to, and only the most adventurous of us are still up to asking the very "where to work from next month" question.
It is incredibly sad to see how herd-able by fear the people are. But, much like in 2008, a sober reminder is that in Mandarin "crisis" consists of two hieroglyphs: dangerous + opportunity.
Be safe & sane, everyone.
This would give those of us who are both tech-people and people-people a tremendous opportunity: to live and work literally anywhere, and have business trips of a few days to ~1.5 weeks long once or twice a month.
With all my dislike of the modern corporate structure, if most of my team is remote, we gather often via video chats, and yet some ~half of us enjoy to see each other in person, which we do by gathering in various places for mini-offsites on the company's buck, as the company clearly understands the cost-effectiveness of such an approach ...
... that's the world I might enjoy living in.
~ ~ ~
Although it's all a distant dream so far. As of today, most places can't even be traveled to, and only the most adventurous of us are still up to asking the very "where to work from next month" question.
It is incredibly sad to see how herd-able by fear the people are. But, much like in 2008, a sober reminder is that in Mandarin "crisis" consists of two hieroglyphs: dangerous + opportunity.
Be safe & sane, everyone.
Sorry in advance for Russian, promise to keep this rare — интервью, которые мы с Тилеком Мамутовым (Outtalent.com) записали в Ололо в Бишкеке. Спасибо, было офигенно, и ты отличный интервьюер!
Forwarded from Грамм Тилека
Дима Королёв (@BoreMeNo) - архитектор программного обеспечения в Poker Stars, преподаватель, основатель Systems Design Meetup. Кроме этого он работал программистом в Google, Microsoft и многих других компаниях.
В этом интервью мы поговорим о собеседованиях по алгоритмам, systems design и о том, как можно развивать карьеру программисту.
https://youtu.be/iYvWLflZ9E4
В этом интервью мы поговорим о собеседованиях по алгоритмам, systems design и о том, как можно развивать карьеру программисту.
https://youtu.be/iYvWLflZ9E4
YouTube
Дима Королев — о собеседованиях по алгоритмам, systems design и как развивать карьеру программисту
Дима Королёв — архитектор программного обеспечения в Poker Stars, преподаватель, основатель Systems Design Meetup. Кроме этого он работал программистом в Google, Microsoft и в многих других компаниях.
В этом интервью мы поговорим о собеседованиях по алгоритмам…
В этом интервью мы поговорим о собеседованиях по алгоритмам…
A system design meetup episode on MapReduce: video, slides. Thanks folks!
And sorry my OBS Studio didn't record your questions this time — good thing I have a habit of repeating them from offline conferences :-) also, I should probably not forget to hide the taskbar next time.
#incrementalimprovements #practicemakesperfect #thanksforhangingalong
And sorry my OBS Studio didn't record your questions this time — good thing I have a habit of repeating them from offline conferences :-) also, I should probably not forget to hide the taskbar next time.
#incrementalimprovements #practicemakesperfect #thanksforhangingalong
YouTube
System Design Meetup 2021-Apr-10: MapReduce
A short episode on MapReduce.
0:00 Warmup
0:29 Intro
1:34 Agenda
2:15 Goal
4:51 Practice 101
9:58 Implementation 101
14:24 Theory 101
29:29 Implementation 201
36:44 Practice 201
38:35 Implementation 301
Slides: http://bit.ly/sysdesignmeetup-mapreduce-slides
0:00 Warmup
0:29 Intro
1:34 Agenda
2:15 Goal
4:51 Practice 101
9:58 Implementation 101
14:24 Theory 101
29:29 Implementation 201
36:44 Practice 201
38:35 Implementation 301
Slides: http://bit.ly/sysdesignmeetup-mapreduce-slides
This important design paradigm has reached me twelve days too late: https://github.com/zhuowei/nft_ptr
Also, copy-pasting and paraphrasing from a private group: The history of C++ repeats itself, the first time as tragedy, the second time as farce, the third as blockchain.
Also, copy-pasting and paraphrasing from a private group: The history of C++ repeats itself, the first time as tragedy, the second time as farce, the third as blockchain.
GitHub
GitHub - zhuowei/nft_ptr: C++ `std::unique_ptr` that represents each object as an NFT on the Ethereum blockchain
C++ `std::unique_ptr` that represents each object as an NFT on the Ethereum blockchain - zhuowei/nft_ptr