I linked to the free online version because that feels like the more HN thing to do, but there's also an announcement post that includes a 15% launch discount on ebook sales:
I'll plan to be around for a bit this afternoon in case anyone has any questions. I've already gotten a lot of great feedback on Learn Enough™ Git to Be Dangerous, so thanks for all the support!
In the United States at least, ™ doesn't mean "pending" per se — you can use ™ even when you have a registered mark, and marks do not need* to be registered to be valid:
> Is registration of my mark required?
> No. You can establish rights in a mark based on legitimate use of the mark.
*: Some countries operate under a first-to-file system, and unregistered trademarks may be at risk even for US-based businesses that operate internationally.
Even if they have the trademark it's reasonable. You just can't use it for a product that might be confused with theirs by a reasonable person. Do you can still make ice cream called that way or probably even name your next novel like that. Just no tutorials on the tech area.
It also depends if they have registered the trademark on the principal or supplemental registers. Trademarks which are descriptive in nature (such as this one) often can't get on the primary register (though they may after extensive use that results in the mark acquiring a secondary meaning). If a trademark is registered on the supplemental register it doesn't afford the owner the right to exclusive use of that mark - even for similar products. All being on the supplemental register gets you is the right to prevent other similar trademarks being registered.
I've often checked things in USPTO's search system (TESS) to see if they're trademarked before I use them, and this isn't coming up for me. Anyone got any insight(?), as if it is trademarked, all my other searches over the years have been similarly inaccurate and pointless :-D
What you're seeing is the difference between trademarks™ and registered trademarks®. The USPTO lists the latter but not the former. You don't actually have to register a trademark in order to use it, but it's usually a good idea. Which reminds me: now's probably a good time to drop a line to my lawyer…
If the Ruby tutorial is any indication, Michael's book will be the best when it comes out. Never gone through any Python tutorials but I've heard good things about: http://www.djangobook.com/en/2.0/index.html, and https://www.twoscoopspress.com/. Take the recommendation with a pinch of salt because I've never done them myself.
Given that Michael's book is 90% about using Rails, I understood the asker's question to be related to using the framework more so than the language itself.
I'm better known nowadays as a Rubyist, but in fact Python was the first language I really loved, and I have over 100K lines of Python under my belt from my Ph.D. research and my first startup. Our planned intro sequence includes Learn Enough™ Ruby to Be Dangerous, but I'm hoping to design it so that I can quickly make a Python version as well.
Among my peers people usually come from a lower level language to either Python or Ruby but rarely switch from one to the other. What made you switch from Python to Ruby?
Also your book set me on my way with Ruby and Rails. I recommend it at least once a week. Thanks for everything.
I don't know one in a similar style, but if you're looking to learn Python as a first programming language I highly recommend https://www.udacity.com/courses/cs101
As far as I remember it it had good pacing and by the end of it I could write useful code (albeit initially brutishly ugly code that I will deny ever having written lol).
It is all custom, and the Learn Enough series is using a variation on our web book layout that we created for the parent platform http://www.softcover.io - which is what is hosting the Rails Tutorial.
I actually learned enough git to be dangerous by reading "Learn Rails by Example." And some TDD, and some Heroku, and some Bootstrap, all as side-effects from the main dish. Quite an eye-opener.
I do offer ebook sales, but of course I'm not selling the individual strips themselves, and the online version is free. Still, your comment has made me realize it's probably a good idea to double-check, so I'll probably drop Randall a line just to make sure.
Thanks! By the way, in the collaboration section I wanted to tell people about the option to host their own repos, so of course I put in a link to GitLab:
There are just some people in this world that have the reputation and thoroughness that makes you only want to learn new things from that one person. Hartl is one of the few. Thanks and can't wait for the rest!
Wow, thanks! Would you mind shooting me an email (address in profile)? I might like to include this comment as part of a testimonial section at some point.
The initial delay when opening the site, before the text appears below is very confusing, at least to me. I didn't know if I was supposed to click on something and tried scrolling up and down to trigger something. The delay lasted more than five seconds on first load and about 3-4 seconds on reloads (could be a problem on my end too).
I've been looking forward to this one. Learn enough command line to be dangerous is the best beginners guide to bash I've seen and it really made me a lot more comfortable working with cli programs.
I just skimmed the first section of Learn Enough Command Line and discovered you can hold option to use the mouse to insert the cursor in the middle of a line.
I thought I knew how to use cli but now I feel like I need to go through this whole tutorial to see what other incredibly obvious things I've been missing.
I would say thats a Unix specific thing more than CLI. It will work on Linux web browsers. Unfortunately three button trackpads seem to be disappearing.
Most Linux distributions by default configure the track-pad to emulate the middle mouse by clicking the left and right button simultaneously. Not as nice as an actual third button, but useful if you are on a laptop without a peripheral mouse attached.
Thanks! As the first title in the Learn Enough sequence, Learn Enough™ Command Line to Be Dangerous was especially challenging to write, because it literally assumes no prerequisites other than general computer knowledge (not even a text editor). So glad to hear you liked it!
I really like this series because of the focus on developing technical sophistication as opposed to a narrow set of boxes to check. I've shared the enough command line to be dangerous with a friend who has flirted with the technical and I think it helped him develop the meta skill of technical sophistication more than any specific command line skill. It's a greater achievement than him knowing the all the flags for tar, because who does?
In any case, looking forward to reading through it and thanks for putting these out there!
Thanks! Developing the theme of technical sophistication has been one of the most surprising and gratifying side-effects of making tutorials designed for complete beginners. I'm hoping to continue the theme in each subsequent Learn Enough tutorial, and I'm thinking of adding it to the next edition of the Ruby on Rails Tutorial as well.
Please do! It really struck me as a theme that I hope grows beyond a Hartl-only concept. It succinctly describes a previously unnamed concept. It's the thing that you want to impart when you get that exasperated feeling trying to explain over the phone to a non-technical friend/relative how to go about fixing something that you yourself don't explicitly know how to fix but could easily if you were sitting at their computer.
More broadly have you though about a generic way to achieve/impart technical sophistication intentionally other than as a side effect of getting scraped knees doing technical things?
More broadly have you though about a generic way to achieve/impart technical sophistication intentionally other than as a side effect of getting scraped knees doing technical things?
I don't think there's any way to avoid getting a few battle scars, but just knowing about the idea of technical sophistication (and having a name for it) turns out to be a huge help, as you observed.
I can't speak for this book, but Michael Hartl's rails tutorial is what got me addicted to programming, and is largely responsible for me switching majors to CS during my undergrad and getting into the industry. He is a great technical author. Give him your money.
Excellent question. The main reason is that GitHub is great for free public repos, which I generally like having as the default, and using GitHub also enables a Secret Bonus™ at the end of the Git tutorial. When it comes to web apps, though, it's better to err on the side of security, so in that case I recommend using free private repos at Bitbucket. (These choices were made mainly because public repos are free at GitHub and private repos are free at Bitbucket. Both services are great and are definitely worth paying for, but in a free online tutorial I prefer to recommend things that are also free.)
This is the first I've heard of the softcover platform.
After some research it looks like it was posted on HN about 2 years ago, but there's only a handful of books posted on the platform compared to let's say leanpub who has a few thousand.
Since you just posted this book on softcover, it's safe to say you're still happy using it, but why aren't more authors choosing your platform?
You would think after 2 years it would have gained traction, especially considering how big your reach is from previously successful tutorials and books.
I'm a content author and softcover looks nice. My main issue with leanpub is that all sales data is anonymous and you can't obtain e-mail addresses of your readers and your platform seems to solve that.
Thanks for the note. Softcover is absolutely amazing for my purposes, but at this point we think the educational market is more promising than the market for self-publishing tools, so that's what we're focusing on now. This was always part of our plan; I personally needed Softcover for the reasons you mention, but it was an open question whether it would take off as a standalone platform or whether we would end up focusing on making our own products.
A happy but unintended side-effect of making a platform is that it dramatically lowers the barrier to collaborating with other authors, and I'm currently working with several other people on more advanced and varied Learn Enough tutorials. This sort of collaborative publishing (with full control over the publication pipeline) would be effectively impossible without Softcover.
So basically you've been spending your time and resources on creating the books rather than promoting the platform?
I will certainly reach out to you in the future because having access to e-mails is enough to move me off leanpub. In leanpub's defense they are a great bunch of people. I've had a number of conversations with their developers and they are always on the ball. Also never had any technical issues with their platform as an author.
The software is awesome for the purposes of writing the book. The reason I didn't go with softcover as a selling platform is that the new EU VAT rules came in and as a result I had to use someone that supported those new VAT collection rules.
So I ended up using softcover to generate the ebooks and html, but using gumroad (and leanpub) to sell them. So it's totally feasible to use softcover for writing your book but self-host the resulting html and keep control of your sales data etc.
In theory, if you are selling to customers in the EU you are supposed to collect VAT from your EU customers and make the appropriate VAT return to the VATMOSS authorities. Or else stop selling to EU customers.
In practice, if you're based outside of the EU then you can probably just ignore these regulations (many smaller US sellers seem to be taking this approach). It's hard to imagine the EU tax authorities chasing you down.
Ok thanks. It sounds like this should be something your payment provider (softcover via proxy through Stripe or whatever they use) would take care of for you.
Other platforms that sell items globally tend to charge EU customers more which probably account for the VAT increase, but in the end gives the author roughly the same amount per sale?
Yes, a lot of sales platforms now handle EU VAT. I've used Gumroad, Sendowl and Leanpub and they all handle the EU VAT problem. In each case the author sets a price. They then detect if the customer is in an EU country and apply the VAT rate for that country, adding it on to the customers total. So the author gets the same amount for each sale, but the customers pay different amounts depending on which country they are in.
A previous thread and its uptake in FOSS showed I really need to get a grasp on Git soon. I'm more about practice than theory so I certainly liked this line:
"focuses on Git essentials without getting bogged down in lots of heavy theory."
Bookmarked it for later when I tackle that. Thanks ahead of time for writing and sharing it.
Is there supposed to be a free book here? The page doesn't work on mobile; I zoom in and a rectangle on the left pointlessly expands, covering the screen.
I've whitelisted all the JavaScript on the site and now an additional annoying box with "keep in touch" is floating over the centre of the page, and if I scroll the page underneath up and down so that the box doesn't cover it I can see "content not available". Is this your first site?
I don't know Elixir yet, but I'm collaborating with someone who does. I think the plan is he teaches me, then I teach you. :-)
I've heard great things about Elixir, and its design is heavily influenced by Ruby, so I think it will be a natural fit for Learn Enough to Be Dangerous.
Additionally a fully featured Phoenix Tutorial would be very welcome as well - however that's probably a silly thing to suggest if you have to learn Elixir first.
Oh, that's definitely planned. :-) Even better, my Learn Enough to Be Dangerous cofounders and I are working on a subscription service that will integrate text and videos for the command line, text editor, and Git tutorials, with many more to come (including the upcoming 4th edition of the Ruby on Rails Tutorial). See http://learnenough.com/ to get some idea of what we've got in store.
The `git push --force` command didn't quite make the cut, but if you can think of a place where it fits into the current tutorial I'm certainly open to adding it. Maybe it fits in as an exercise somewhere?
UPDATE: yebyen has suggested this was a meant as a joke. If so—good one!
UPDATE 2: I don't mean to imply that force-pushing isn't useful! As several commenters below have noted, it most certainly is. But it's also most certainly dangerous.
I've seen `git push -f` used quite a bit over my career. Maybe it's bad practice, but it's useful for:
1. Organizations that want single-commit branches (e.g., where there's a lot of cherry picking going on in a git-flow style to get certain features pushed out) but you also want to keep 'savepoint' commits while developing. Squashing a bunch of commits requires a -f if you've already pushed.
2. Rebasing a branch (without making a bubble merge).
3. For truly small quick fixes you notice when you've just pushed to CI (like you left in a debug or a focus on some tests).
Much more than that. `git push -f` and `git rebase -i` are essential tools to keep a history where every commit passes CI. And that is very important for `git bisect`ing things later.
They are also necessary to keep a history where `git blame` can be used effectively.
Rebasing shared branches is pretty nasty. Do people really keep a policy of "every branch must pass CI" ?
I like rebase on my branches so I merge as a single commit at the head of the branch I am merging into, but rebasing a shared branch is total ick.
As for needing every branch to pass CI forever to use git bisect.. that seems a bit extreme. I think I have used git bisect like 3 times in the past 5 years? And each time I wrote a very simple unit test and fed it into git bisect and was able to figure it out without a problem. If you are using git bisect constantly I guess I can see, but that has another smell. Who cares when it was broke, just fix the broke thing!!
On shared branches, I think the rules are different. Rebasing a shared branch is very sticky. But for single-dev branches, I think rebasing/forcing is fine -- do what you want until it enters the main stream.
git -f on a shared branch is a surefire way to lose commits. OMFG. It's better not to allow it at all. git revert will undo damage adequately, just not cleanly.
I think that was supposed to be a joke. Enough git to be dangerous... what about some dangerous git command which potentially destroys some important history... [stopgirl.gif]
Your books are great, I've been buying Learn Enough to be Dangerous preorders for topics I already know well because I learned so much from the Rails Tutorial dot-org. Thanks!
Heh, I almost replied that `git push --force` might be a little too dangerous! But the truth is it barely didn't make the cut, and I wouldn't mind finding a place to work it in.
Apparently we both need to write better, because you missed the point of my example. Most—if not all—local changes that would be destroyed by git reset --hard show up in git status.
git clean -dfx will wipe out ignored files, which do not show up in git status, so it's much easier to forget about something you meant to keep.
I've never used 'git clean -dfx' routinely during development. On the other hand, I've seen a colleague lose a few hours' work by forgetting to commit a specific file out of a set, and then doing 'git reset --hard' for some reason. 'git status' didn't save him. Luckily, he did commit the corresponding tests file.
Thanks! There's also another variant that I created that we are using for our beta testing "Special Ops" team signup page: http://www.learnenough.com/special-ops
http://news.railstutorial.org/learn-enough-git-ebooks/
I'll plan to be around for a bit this afternoon in case anyone has any questions. I've already gotten a lot of great feedback on Learn Enough™ Git to Be Dangerous, so thanks for all the support!