Marc Köhlbrugge
PRO
@marc
This seems like an elegant compromise: andycroll.com/ruby/stop-robot…
It tracks 404's, except those generated by crawlers that might crawl outdated links.
In addition to what @ronald93 says:
"Sign in with Twitter" provides you with a confirmed email address. I'm pretty sure that when a user has not confirmed their email address the Twitter OAuth flow won't provide the email. (I ran into a bug related to this, hence I looked into it).
The same is probably true for Facebook and many other OAuth services. Just make sure to double check they don't provide you with unconfirmed email addresses (i.e. create a test account to see what happens).
Another more novel, but not fool-proof way to verify an email address is to have the user send you an email. I one saw an "email sign up forms" that was just a mailto: link. When the user sends an email to that address he/she got subscribed to the newsletter. However, it's not fool-proof since it can be faked.
They don't hang out on the internet, they are reading books :D
More serious answer: Goodreads.
I am making a small website that would be useful for book readers. Where can I promote my product?
Still Goodreads, but damn, that site is ugly. But this is where my community is hanging, so...
It's probably time I worked my way through a course to make better use of branches etc. And probably time I wrote some tests too! :D
Haha yeah, but take it one step at a time. I feel like I haven't even scratched the surface of Git myself. But whenever I encounter a problem or notice I keep doing the same thing over and over again, I look for ways to improve my workflow. It seems like you just hit one of those issues yourself (hence the question).
Does this mean you try to include the 'why' in your commit messages rather than just 'fixed xyz / added abc' type notes?
Only if I feel like it's needed. I have plenty of "fix foo", and "add bar" type of messages though. It really depends on the circumstances. But just having every incremental change accessible separately by itself is already very valuable. For example you can go to a specific line of code and see all previous commits that touched it. So if you wonder why a piece of code is the way it is, you can just look up those commits which will help you jog your memory.
Nowadays I tend to use just the one device (MacBook Pro), but I still choose to use Git. Some of the benefits for me:
- Saving incremental changes so I can easily revert back in case any problems arise. This also gives me more confidence to experiment within my code.
- Being able to create branches also lets me experiment with new ideas without the fear of messing up my code.
- Let's me use Continuous Integration that automatically runs my tests and rubocop (checks for coding style violations)
- I can access my code everywhere. More than once I've fixed a wipbot bug on my iPhone! (pull code the code, make the fix, push the change)
- It makes it easy to collaborate with other developers now and in the future
- The commits are a way to document your code. So if in a year time you're wondering why you made a certain change, you can quickly find it.
- My code is backed up in multiple places at every stage
- Any merge conflicts are handled automatically when possible or are relatively easily managed manually (versus syncing app that are not optimized for code)
Using Git does indeed come with the requirement of committing and pushing your code. I believe it's a habit worth developing though for the reasons above. There are also some tools you can use to make this easier. For example my Terminal is set up such that it shows when there uncommited or unpushed changes in my working repository.
Do you plan on writing code for the foreseeable future? If so, then I recommend investing in a workflow that will let you reap the rewards long-term.
Excellent answer, thanks Marc. I only started using Git about 18 months ago and though its now an established part of my workflow I'm definitely not using it to its full potential at all. I largely use it for 'i finished, push to production' and only when i remember to for 'heres a good place to save my work'.
It's probably time I worked my way through a course to make better use of branches etc. And probably time I wrote some tests too! :D
The commits are a way to document your code. So if in a year time you're wondering why you made a certain change, you can quickly find it.
I thought this was a really interesting bullet. Does this mean you try to include the 'why' in your commit messages rather than just 'fixed xyz / added abc' type notes?
It's probably time I worked my way through a course to make better use of branches etc. And probably time I wrote some tests too! :D
Haha yeah, but take it one step at a time. I feel like I haven't even scratched the surface of Git myself. But whenever I encounter a problem or notice I keep doing the same thing over and over again, I look for ways to improve my workflow. It seems like you just hit one of those issues yourself (hence the question).
Does this mean you try to include the 'why' in your commit messages rather than just 'fixed xyz / added abc' type notes?
Only if I feel like it's needed. I have plenty of "fix foo", and "add bar" type of messages though. It really depends on the circumstances. But just having every incremental change accessible separately by itself is already very valuable. For example you can go to a specific line of code and see all previous commits that touched it. So if you wonder why a piece of code is the way it is, you can just look up those commits which will help you jog your memory.
If you're a developer you can also create your own scraper. A tool like SelectorGadget lets you easily generate a CSS selector that points to the data you need. You just need to write a script that extract the data based on that CSS selector.
There have been a few discussions about this in the chat.
In short:
If I could flip a switch and have user-specific deadlines I'd do it, but it's just too difficult right now to get right. Your feedback (and those of others) is noted though. If there's any experienced Ruby developers that are willing to take a stab at it I'll consider providing repository access.
Ah ok thanks for the response!
I understand it's a difficult technical/UX problem. If I can think of a novel solution, I'll be sure to mention it.