Deploying with git

Git is an excellent version control, but it’s more than just that.  A lot of people use it to deploy their projects as well.  Most suggestions (for example, this tutorial from Digital Ocean) around the web employ the post-commit (or other) hooks to push the code to a remote server.  While this works well, I prefer to do it differently.  I like the pull model better, where the deployment is triggered outside of git, and relies on git to fetch the code updates and run some sort of a build script, which handles database schema changes, cache resets, filesystem permissions, etc.  Such approach also allows to limit remote access to the servers (especially the production ones), and separate responsibilities of a developer and a deployer.

With the many pull, merge, fetch, and update options that git provides, it is sometimes difficult to choose what’s the right set of commands to use.  I’ve figured it out via a rather lengthy trial-and-error process.  But if you don’t want to go through all the pain of that, here’s a nice blog post that tells you exactly how to do that.  I’m copy-pasting the commands here just for the future reference.

cd "${DEPLOY_TREE}"
git fetch --all
git checkout --force "${TARGET}"
# Following two lines only required if you use submodules
git submodule sync
git submodule update --init --recursive
# Follow with actual deployment steps (run fabric/capistrano/make/etc)

And I suggest you read the full article for the explanation of why this is a better way and what are some of the issues with other strategies.

 

OpenAPI Specification

OpenAPI Specification v2.0 – formerly known as Swagger RESTful API Documentation Specification.

Swagger™ is a project used to describe and document RESTful APIs.

The Swagger specification defines a set of files required to describe such an API. These files can then be used by the Swagger-UI project to display the API and Swagger-Codegen to generate clients in various languages. Additional utilities can also take advantage of the resulting files, such as testing tools.

have i been pwned?

With all the security breaches  going around, it’s hard to keep track on which sites got broken into, what was stolen, and, most importantly, if you are affected.  have i been pwned? website provides a very simple interface to check if your account data was leaked, across more than a hundred websites.

pwned

Try it out … you might be surprised.  Like I was. :)

JavaScript debugging tips

I came across this blog post which provides some very handy tips for debugging JavaScript in the browser.  My favorite top three are:

Display an object in a table format for an easier view

var animals = [
   { animal: ‘Horse’, name: ‘Henry’, age: 43 },
   { animal: ‘Dog’, name: ‘Fred’, age: 13 },
   { animal: ‘Cat’, name: ‘Frodo’, age: 18 }
];
 
console.table(animals);

with this output:

console.table

Unminify code as an easy way to debug JavaScript

unminify

Custom console log messages

console.todo = function(msg) {
	console.log(‘ % c % s % s % s‘, ‘color: yellow; background - color: black;’, ‘–‘, msg, ‘–‘);
}
 
console.important = function(msg) {
	console.log(‘ % c % s % s % s’, ‘color: brown; font - weight: bold; text - decoration: underline;’, ‘–‘, msg, ‘–‘);
}
 
console.todo(“This is something that’ s need to be fixed”);
console.important(‘This is an important message’);

for this result:

console.log

Very handy stuff!

Bitbucket Pipelines Beta announced

BitBucket blog announces Pipelines Beta (coincidentally after I’ve spent about a week playing with Jenkins).  These guys are dropping their Bamboo Cloud CI solution and instead provide this:

It looks a lot like TravisCI, but on steroids!  Very good news!

GitHub private repository contributions on your profile

GitHub blog says that from now on your profile can include the private repository contributions on your profile.

github private repo contributions

When enabled, these can make quite a difference in the number of the green boxes, showing your GitHub activity.  Here’s an example from mine.  Before enabling those, showing only Open Source contributions:

GitHub mamchenkov before

And here’s one after, including private repository contributions:

GitHub mamchenkov after

Indeed, it is a more accurate representation of my GitHub activity.  Given that these days most of my private repository activity happens on BitBucket and not on GitHub, this is quite surprising.

GitHub unlimited private repositories – a better world or a perfect disaster?

github unlimited repositories

Today I was super excited to read the following in the GitHub blog:

We couldn’t be more excited to announce that all of our paid plans on GitHub.com now include unlimited private repositories. GitHub will always be free for public and open source projects, but starting today there are just two ways to pay for GitHub.com:

  • Personal: $7/month
  • Organization: $9/user/month, $25/month for your first five users

One of the very best things about Git and other distributed version control systems is the ability to create a new repository without asking permission or getting approval. While this has always been true for our public plans, it hasn’t been the case for individuals and teams working together in private. All that changes today.

After all, it was the pricing around private repository that pushed me towards BitBucket.

Working for a small startup with a small development team and lots of client projects that require private repositories, GitHub was too expensive of an option.  So we’ve moved all private repositories to BitBucket, which charges for the team size.  We still use GitHub for all of our Open Source work, and for the client projects where we need to work with external teams (usually, developers on the side of the client).

Can we move all our stuff back to GitHub and just use a single service for all our code, pull requests, code review, etc?  That would make a world a better place.  Let’s see …

github

Wait, what?  Our GitHub organization has 5 members and 18 external collaborators.  And, well, another 5 pending invitations to the external collaborators.  But all of these are summed up into the 28 users (!!!).  Currently, we are on the Bronze $25/month plan, which comes up to $300/year.  The new plan with unlimited repositories, as indicated on the screenshot above, will be $2,784/year.  That’s almost a 10 times increase!

Thanks, but no thanks.  Right?  Well, not really.  The GitHub blog post also says the following:

We want everyone to have a plan with unlimited private repositories, but don’t worry—you are welcome to stay on your current plan while you evaluate the new cost structure and understand how to best manage your organization members and their private repository access. And while we’re currently not enforcing a timeline to move, rest assured that you’ll have at least 12 months notice before any mandated change to your plan.

This is not very friendly.  This means that while upgrade to the new plan is now optional, it might not be so in the future.  Sure, you’ll get a warning ahead.

Dear GitHub!

I understand that you are a profit-oriented business and you need to make money.  But I think you’ve made a mistake somewhere here.  I hope you’ll re-evaluate this thing.  Otherwise, I’ll have to move away – either to BitBucket or GitLab.  And it’ll be a sad day.  I know, I’m not your largest client, but I’m sure there are many like me.

Yours truly, Leonid.

Furthermore, thinking about this, I suspect that external collaborators are being charged twice.  Sure, they can have their own repositories as well, but collaboration often involves forks and merges between multiple repositories of the same project.  So, to support this collaboration, I need to pay for the external collaborator to have access to my private repositories, while he also needs to pay on his side to be able to fork the private repository into his organization.

I think organization shouldn’t be charged for external collaborators.  Extra features for organization members – like team-mentions, finer access control, etc – can provide the incentive for the companies to pay.  But the way this looks now is just too much.

28 Ways to Secure WordPress Website

28 Ways to Secure WordPress Website covers, as the title says, quite a few ways to make your WordPress website more secure.  There is no absolute security, and there are always more that you can do, but this is a good start.  Apart from all the useful advice, the article also tells you why you should care:

“Why would anyone hack my site?” – you ask

Let’s be clear. Your site is likely not special. Unless your firm’s name is CNN.

The fact is that most – or the great majority, rather – of attacks are automated. This means that various bots (pieces of software) developed by hackers crawl the web and look for vulnerable sites.

Then if they’re successful, the site gets added to the hacker’s portfolio, so to speak, and can be used for various purposes.

In other words, your site by itself is no special, but 10,000 sites just like yours is pure gold for a hacker. Such a network of hacked sites can be used for things like black hat SEO, mass email sending, database scraping (to get your users’ personal info), and so on.

You really shouldn’t feel overly safe just because/if you run a relatively small website.

Hackers don’t discriminate.