I used this technique in my forms until I realised that the browser's auto-fill also works similar to the bot and will fill fields that has a familiar field name (email, name phone etc). Real users (many of them) who use browsers auto-fill feature will get blocked by this technique. If you add a field with a random field name bots ignore that field.
One thing that works still is using Javascript to create a hidden field and make that field mandatory. Run of the mill bots don't run Javascript yet. However this will exclude people who have disabled Javascript in their browsers.
It seems to follow the notion that more comments = better code.
If the symbol names are explanatory enough, the code itself will be self-explanatory. Then all that must be commented about will be special cases handled/not handled and why a certain decision is taken about handling in a certain way.
Often, "every single line is commented" results from blindly following a certain "Standard" that demands that. Eventually generating meaningless comments all over the code.
Then the important points never gets mentioned in the comments or just gets buried in the noise.
I invested a lot of time trying to publish a Gmail add-on and failed miserably [1][4] because of this lockdown. Here are some notes that may be of interest:
The lock down is for the Gmail API especially for API that allows reading user’s email.
Any App has to get OAuth 2 token to get access to the API. The user has to explicitly provide access . The approval screen will show each type of access the app is asking. See an example here [2]
In addition, Google will send an email to the user immediately after the approval, with a scary warning.
The user can withdraw the app access anytime, from Google account page.
The data access concern Google is projecting is that the APP can read user’s email (Remember, the app can read only those who explicitly gave the app the permission to read their email).
The “lockdown” is a direct reply to the media frenzy that “Gmail allows any app to read anyone's email” [5]. Gmail does not allow reading email automatically. The user has to allow explicitly.
In order to get Gmail API access, the app has to go through a Google review process where Google will ask the developer to justify each type of API access the app is requesting in addition to explaining (with videos) what the app does and how the API is used.
The first level of approval process demands you to publish a comprehensive privacy policy and in my experience, anything like “marketing” or “research” in the privacy policy will get you disapproval. [3]
Such a strict approval process is good and fine, and well appreciated till this point. The issue comes for the last part of the approval process.
Those Apps that requires read access to Gmail has to get themselves assessed, through Google appointed third party security assessors paying $75000 USD annually.
This is the main blocker.
This will kick out any app or add-on that small scale developers create. It will block new entrants. What remains will be established apps that are generating huge revenue to justify the “protection money”. They get an added advantage that there will no longer be any new competition.
It is not the restrictions, or the intention to protect the end user that is in question but the “first save my back” attitude in the process, and the bait and switch - that is the problem. In summary it happened like this:
Hey developers come, build apps using our platform, show your innovation!
Developers start investing time and effort on the platform, approval process is smooth and fare
Somewhere else, someone misuses someone’s system, huge media attention
Sorry developers, you go to Mr X , keep paying him and we will keep you here. If not, trash your product and go away.
I survived more than 3 hard-drive failures/system failures over the years without losing my data. My system setup helped in the survival so this might help. I had desktops and laptops that died, crashed or otherwise became unusable. The data survived. Here is what I do:
I have three categories of files: (1) small, very important files (source codes, scripts, articles, notes, documents) (2) large but important files (photos & videos, Virtual Machine images ) (3) unimportant files (downloads, temporary files, screen captures)
3 main folders are setup for each category. Category 1 is backed up to (1) a cloud based continuous back up service (crashplan) (2) gitlab as part of version control (3) local external HDDs daily
Category 2 is backed up to (1) crashplan and (2) local external HDDs
Category 3 is never backed up.
Having a copy in local external HDDs helps in quick recovery.
Organising the hard drive keeping a unexpected crash in mind helps in quick recoveries.
I have dokuwiki installed on my macbook pro. Having a quick reference conveniently on local laptop is important for me because I should be able to access it even when offline. Having access to the wiki from different devices is not that important. Hence no cloud-based solution. The local wiki is added to the 'hosts' file. so http://mywiki in browser brings up the wiki quickly. Installing dokuwiki on mac is quite easy by the way.
The sidebar of the wiki has items like: ideas, tomorrow, to-read, references, and items for each of the project I work on.
When an idea strikes, I add an entry in the ideas folder . This helps because I know that it is 'filed' for later reference and as it is out of head, I can continue working on whatever I was working on.
One advantage of the wiki over things like paper notebook is that it is quite searchable.
For example, once I stumbled upon one video about a 'water from air' project (making water available in remote deserts by extracting water vapour from air). I filed it in a sub-page under "ideas " along with links that I could find. Then moved on. Didn't come back to it for quite some time. Then one day in some other discussion, the topic came up. It was quite easy to get back the links and references from the local wiki.
The wiki pages are plain text files that I add to backup scripts (local and cloud). So it survived system failures in the past.
One thing that works still is using Javascript to create a hidden field and make that field mandatory. Run of the mill bots don't run Javascript yet. However this will exclude people who have disabled Javascript in their browsers.