Just wait until you learn about Bitcoin
4,848 karma · joined November 17, 2009
Contract calls are executed by every node on the network -- if you've heard of "embarrassingly parallel", Ethereum is "embarrassingly serial". That is, every function call, on every contract, is run by every (full) node on the network.
The calls are deterministic which means that the nodes can verify that their peers calculated the outcome correctly and didn't try to cheat.
It sounds expensive (and it is) but that's the (current) cost of decentralized, trustless computation.
This guide is intended to provide orientation for someone who knows very little about cryptocurrencies. Many are quite different in scope (and legitimacy).
I hope no one makes investment decisions on just four words. It's just a taste to help you find what you might be interested in pursuing further.
By the way, if you're interested in learning the hard-core technical details of programming cryptocurrency, you find more of my in-depth material here: https://www.newline.co/
If you have a better four-word description of what any coin is for, post it below and I'll make updates.
This list is designed for minimal orientation. The difference between e.g. hashing algorithms or block time is inconsequential at this altitude.
Here's the Google Doc: https://docs.google.com/spreadsheets/d/151E3d26SIRNhXQewq-55...
Assuming that the publisher openly states they're mining instead of showing ads, and the user understands what's happening, browser-based mining is an attractive alternative to ads.
The first benefit is in privacy: you don't need to track your users personal preferences or identities. The second benefit is that there's no signup, no login, and no fraud.
It does not wholly solve the issue of attention-based revenue. That is, there is still some incentive for publishers to "manipulate" the user into long session times on the site. However, unlike ads, long session time doesn't have to mean long attention time in order for mining to happen.
Browser-based mining is sort of like micropayments: the user is paying the site in electricity. Many people don't want to pay subscriptions and they don't want to see ads. Browser-based mining is a viable alternative.
I've found that smart contracts have a lot of jargon that can be opaque, but the concepts are familiar to web developers (and not that hard to learn).
For example, in traditional webdev we use our browser to connect to an app server, which is connected to a centralized database.
In Ethereum dev, every node has a copy of the entire database. To write distributed apps, you read from your local copy. That is, for a JavaScript DApp, you use the web3 JavaScript library to connect to a local node you have running on your own machine.
Writes are little more involved, because you need the network to agree that your writes are valid. So to perform writes, you submit a transaction to the network.
The result is reads are free and writes cost money.
Solidity is tricky, but not that bad if you're careful. If you know JavaScript already, you can totally learn to program smart contracts.
In any case, my site is here. I'll be making the first course free shortly: https://www.newline.co/
In our version you're able to bid for each pixel -- if the previous owner is outbid, the funds are returned. Sending funds in Solidity from a contract is really tricky to handle because there are so many ways it can go wrong.
For example, when you send funds to an address, it can purposefully reject your payment and even call back into your own functions. This is like if when you called a REST API, the API was potentially malicious and could call any public function in your code (!).
This is a really fun project and it's cool to see how you can connect web-apps to the Ethereum network.
With Ethereum we have decentralized compute. With IPFS we get decentralized storage. Cryptographic keys give us self-sovereign identity. Build tools like Truffle make it easy to get started (think create-react-app for Ethereum). And libraries like Zepplin are helping standardize secure patterns.
And, to top it off, using web3.js we can write UIs _in the browser_ using JavaScript and the libraries we're already familiar with (Angular, React, Vue).
By the way, [shameless plug], if you're a web developer and you're looking to get started programming cryptocurrency and distributed apps, I have some introductory tutorials here => https://newline.co/
I've written a book on both Angular 2+ and a book on React. I've talked w/ hundreds of developers on both sides and I can tell you that people with different constraints (and backgrounds) will have a different response.
The author of this article cites "more ReactJS libraries on npm" to imply that React is the better choice. Some people love a la carte infrastructure and the power that comes from choosing each element in your stack.
Some people love to have those decisions made for them, because they just want to build their app.
It's often cited that React is "simpler" than Angular, and if you look at just the core that's true. But by the time you pick a data architecture, styling choice, router, etc. you're back at the same level of complexity.
Actually in React, you've spent a lot of time researching which components you want (and if they'll even fit together). The pro here is that you get just the stack you want! The competitive evolution of these libraries means that you _can_ have 4 routers and pick the best. But also, if you'd just picked Angular, you just use their router and move on.
Here's another litmus test: Do you want 'string' templates or JSX? (Now, I know it's technically possible to do either in both frameworks, but it's almost never done in practice.)
Almost everything that seems "more complex" in Angular is a result of string-based templates. DI, AOT, the *ngIf and `let` syntax, is all because you're doing templates in strings instead of code. How do you feel about that? Would you rather write templates in JavaScript/JSX? Then use React. Do you have designers doing HTML on your team? Then use Angular.
(Also the other opens by citing webpack, npm, and third-party libraries as a React-specific benefit, but that makes no sense because angular-cli uses Webpack, it's on npm, etc.)
This idea of "hustle as your new second job" is a better phrasing than my parent comment where it sounds like I'm implying that self-promotion is bad or somehow empty.
Becoming a personality is an excellent strategy - if you're known and loved you'll never starve.
I'm mostly trying to point out that time spent hustling takes away from time building. It's still valuable in it's own way, but many OSS devs (who have created software people find valuable and use) don't want to travel to speak at conferences to pay their bills.
One might say that other open-source projects don't make a significant income because they don't have value, but I think you only need to look at e.g. the npm download stats for many packages to see that this isn't true.
Put another way, _many_ software libraries enable huge amounts of business value that is not captured by the authors of those libraries.
For instance, if you're a JS dev, you've probably used lodash or moment, but maybe can't even name who the authors are of those projects.
Here are your choices:
* Turn your OSS project into a company (Docker). The pro is that you can capture a lot of the value, the con is that you're splitting your project into CE/EE and also now you're a CEO
* Give the software away for free and charge for the hosting (Gitlab). Pro here is that you get recurring revenue, but the con is that now you're in DevOps and wear a pager. Also this model doesn't work well for libraries, only "apps".
* Charge for support (Ubuntu, Nginx-ish). Pro here is that by helping folks implement your software, you'll have a long line of success stories. Con here is that it isn't scalable - your upside is bounded by the hours you can bill
* Get a job at a company that will fund you to work on it (React, Angular). Pro here is that you can make tons of money with a job you love. Nice work, if you can get it. Con is that now you work for that company and you're subject to whatever whims they have.
* Run a Kickstarter (Light Table, Diaspora). Pro: you can gauge demand and you don't have a boss. Cons: it's one-time revenue, you have potentially inflated expectations, and just kidding, now you have 1,000 bosses.
* Run a Patreon (Vue). Pro: you have autonomy and recurring revenue (yay!). Con: now you're a personality. This is limited to celebs who are good at marketing _themselves_ as much as their software
* Ask for donations (Babel, Webpack). Pro: this works for tools and libraries (not just apps) and you can keep your mission. Con: Companies feel these donations have ambiguous deliverables. There's a lot of mental overhead too (How many projects can one company fund per month?)
* Sell documentation, books, videos (React Training, my current gig). Pro: JavaScript fatigue makes you money! Con: Writing the docs isn't as satisfying as writing software (for many developers)
So to answer your question: monetizing your open-source project means you take on another job _besides writing software_.
In an ideal world if you write software and it gets used, you'd be able to capture some share of that value. But we're not there yet.
[If you want to chat more about funding OSS, reach out to me (see my profile). I'm working on a few new ideas.]
Shameless self plug: our book [1] has a whole chapter on Routing in React with this new v4 router. After you've finished reading the docs, if you want a tutorial style walk-through of this router v4, we build a Spotify-type clone over the course of 75+ pages.
brew install homebrew/dupes/expect
# find the expect/tcl path with this command
otool -L /usr/local/bin/expect
export TCLLIBPATH=/usr/local/Cellar/expect/5.45/lib
autoexpectIt lets you write a (static) document that mixes prose and code in a way thats best for the reader. But 1. the code is runnable on disk and 2. you don't have to copy and paste.
Generally I find that literate programming solutions don't have good support for hiding portions of the code. This tends to limit the tool's applicability to trivial code examples.
I use `cq` to extract key code blocks from complete projects and then provide the whole project alongside the post.
React is great as well, but if you find Angular incomprehensible it's not clear you'll find React much easier.
One major difference between React and Angular is that the Angular community _tends_ to separate their templates from their "controller" code, whereas the React community _tends_ to intermix their templates with code ("PHP" style).
The result is that in Angular you have a few funny characters in your HTML to learn (e.g. `*ngFor="let foo in bar"` for looping) whereas in React you'll use JSX and use JavaScript for loops.
It's pretty clear to me that component-based webapps are here for the long haul. Even if WebComponents ends up being the future, the concepts you learn in using either Angular or React will be more-or-less transferrable.
It seems to me that Angular and React are becoming more similar over time. For typing, Angular uses TypeScript and React uses Flow. For data architecture, both communities are gravitating towards some sort of Flux (redux / ngrx). You can even use JSX in Angular if you want to.
Shameless plug: I've written a book on Angular 2 which talks through, step-by-step, how to understand Angular. The first chapter walks you through your first app and you can get it (for free) here: https://www.ng-book.com/2/
That chapter will be an in-depth guide to unit testing React generally, but we'll introduce testing some of the example code in other chapters earlier in the book.
I've been here at HN long enough to know that a few of you might take issue at our pitch of learning React "The Right Way". Obviously there are many, many opinions on how to write React apps and there are many good ways to approach React.
But I think a large part of so-called Javascript fatigue comes from the fear of being wrong.
Because React is so modular there are tons of different modules for every idea. "Awesome" lists are egalitarian and often put libraries of vastly different popularity and stability right next to each other. In most cases the community has already gathered behind one or two libraries, but it takes a lot of research to figure out which one (and it's especially hard if you're a beginner).
What we're offering here is a well-researched, coherent, code-packed resource. We'll tell you which libraries to use and how to use them and you won't have to piece together hundreds of blog posts. We've kept our books on Angular up-to-date for years now and we're planning on doing the same for this React book.
You can of course learn Angular 2 from lots of disparate blogs on the internet. There's lots of good resources. But the goal of our book is that you'll be able to learn everything, in-order, in one place.
We've been keeping the book updated alongside Angular's development (though it will take us a few days to get up to the most recent beta). We've already updated the book over a dozen times, so I think you'll really like it.
If you like this style of thing, check out the rest of TJs work at his website: http://www.tjfullerswebsite.com