Source: Custom-share-methods by ptasker
This is more an informational post for myself, but here’s some nifty commands that help debug what’s going wrong on a server when things aren’t going right.
These are good for watching WHO is hitting your server and what their IP is. netstat -tn shows the unresolved address, so you should get the IP’s of possible spammers
Once you’ve got the IP(s) you can block them with iptables like so:
iptables -I INPUT -s <IP ADDRESS> -j DROP
Another good tool for watching network traffic is iftop. You’ll need to install this one via Yum or Apt though:
iftop -N -i eth0
And for overall machine health, nothing beats good old htop! Ahh, CPU usage back to normal.
One of the early struggles I had with the framework was the concept of async code and callbacks. If you follow most of the tutorials and docs, you’re encouraged to write anonymous function based callbacks.
While this works for a simple application, when you start to scale, things get ugly – i.e. the Christmas Tree of hell:
Obviously, this way isn’t readable or maintainable. There’s also the issue of errors needed to be handled at each level of nesting. Not good and repetitive.
One of the oft-talked about solutions is Promises. Promises promised to be an easy solution. The concept of promises in async programming is talked about all over the internet, and I had a hard time understanding it at first. I eventually got the hang of it and tried to convert some code to use the Q module:
Great, looks good, relatively clean and it includes exception handling by default. Christmas tree is gone!
I did run into a few issues/shortcomings for me, that bothered me a bit.
First, most NPM modules don’t use promises internally, like mongoosejs. This is a problem since this now requires me the developer to inject promises into the callbacks (that’s what the Q.defer() is all about). While not a big deal, it’s a bit of an annoyance to start converting all my callbacks to use this syntax.
Additionally, I wasn’t able to successfully pass multiple arguments to successively linked functions. The docs for the Q module say you can nest promises to get multiple inputs in your closure, oh yay!
I see a Christmas tree appearing…
So after trying out promises, I came to a solution that worked in my situation. I stumbled across this blog post on NodeJS structure, Callback hell is a design choice. And suddenly, a lightbulb appeared.
You see, you don’t need to use anonymous functions as callbacks, you can pass in pre-defined functions. And with the handy-dandy bind() method available in ES5, you’re able to pass contextual variables to nest callbacks. Awesome.
Here’s what I finally came up with:
So you see, in the first method kickOffTwitterCall() I’m assigned things I want available to nest functions to ‘this’ reference. As long as each callback uses the .bind(this) I’ve got access to anything assigned to ‘this’.
There’s also the added benefit of being able to pass extra args to bind which will then be available in the callback:
I have no doubt promises have their place, and I intend to use them when possible, however in some situations, they’re just not the right fit. For me it was about code organization and readability, and bind() was able to accomplish what I needed. +1 for learning new things!
Digital Soup for the Soul: Find the Integrated Development Environment (IDE) that’s right for you.
So, what’s the best IDE?
To try to answer this question, here’s a peek into a typical conversation among High Road developers:
Peter: “What IDE do you use?”
Peter: “Ever heard of PHPStorm?”
Kris: “Visual Studio anyone?”
Mike: “Seen Brackets in action yet?”
Chris: “Back in the day…”
You get the picture: there are many IDEs available and which one is best for you depends on a few factors. While the majority of IDEs easily perform most coding tasks, there are others that stand out for specific programming languages and/or types of development. They do this by offering a few extra “helpers” to enhance the experience.
(This is part 1 of a series on WordPress security)
Online security is has been gaining alot of attention in the media recently, and with good reason. With much of our lives now taking place online, security is something that effects all of us.
The recent ‘Sony Hack’ and the iCloud photo hack were just 2 of the many security issues in 2014.
WordPress specifically was effected with the SoakSoak malware effecting over 100,000 sites.
With security on the top of everyone’s mind, I thought it was a good idea to list some resources for securing, hardening and locking down your WordPress installation. This guide aims to expand on some of the concepts in the “Hardening WordPress” post on WordPress.org (http://codex.wordpress.org/Hardening_WordPress) – read this first.
After all, WordPress security is worth the investment if you’ve spent the time (and money) curating and writing a blog.
Keeping things up to date
This is an obvious one, but as the Hardening WordPress guide states, “you should always keep up to date with the latest version of WordPress”. I would go even further, and say that you should always keep up to date with the latest versions of plugins and themes. The WordPress auto-updater is coming along but only works with minor point releases and doesn’t update plugins OR themes. Keep those themes and plugins up to date!
The next simple thing you can do to keep your WordPress site secure is sign up for some security and monitoring services. Not all of these services are free, but if you or your client’s website is a source of revenue, the small fees are well worth the investment.
I’m a big fan of Sucuri and their Malware removal tool (referral link) and it offers a great peace of mind knowing that they’re monitoring my sites and are available for quick malware cleanup’s if needed. They send out notification emails each week letting you know of the status of your site(s). Awesome.
They also have a Web Application Firewall (WAF) that’s similar to CloudFlare. I haven’t used it but it seems cool.
Secondly, VaultPress is an excellent service for backups and security monitoring. I recommend the ‘Security Bundle’ for all the clients I work with, and for $29/month, quick backup restores and monitoring are taken care of. Heck, even the $5/month plan is a great deal for their service that backs up your site code, files and database to the cloud.
CloudFlare is a free DNS and CDN service to protect your site from spammers and provide some base level of speed increase. It’s an additional layer in front of your site that will intercept some illegitimate traffic and bots.
You can configure how much or how little CloudFlare caches, and what level of DDOS and security protection you get. There are other options for restricting spam users and IP’s from the CloudFlare control panel.
It’s worked pretty well for me, the only drawback is that is requires pointing your DNS at CloudFlare’s servers. This could be a deal breaker if you don’t control you’re DNS (or don’t know who to ask). There’s also the whole privacy issue with funnelling your traffic through CloudFlare’s infrastructure.
Website monitoring services, like New Relic, AppDynamics or even Pingdom, are also worth mentioning. Though not specifically related to security, they are great for knowing when your site goes down and what caused it (like a spike in spam traffic).
There are a whole host of other security related services and tools out there, which ones do you use?
Next post – Security plugins!
One of the issues us as developers face daily is the concept of deployment. Especially with a CMS. Here’s an overview of some of the tools and approaches out there.
Deployment (or environment syncing of dev > stage > production) of a CMS/Website has the following components:
- Deploying code
- Deploying a database
- Running post deploy scripts.
Typically deployment is one way, from development to stage to production, although all the below can be performed in the opposite direction.
The following are some of the common methods of deployment:
Via (S)FTP or file syntonization – Old school
The old school method of deployment is by using scripts or manual process is to mirror dev, stage and production environments. Steps in this process involve manually exporting a database script and deploying that database to the staging or production environment. For files, they are copied directly to the staging/ production environment. Major drawbacks of this method are deployment tracking is lost and there is no easy rollback.
A newer and currently popular method for deploying website/CMS files is by using git. With a git deployment strategy, a git remote target is setup (either staging or production) and a git push is run whenever these environments need to be updated. This however only updates CMS files, and not a database. Post deploy hooks can be called on the target server to mimic database changes and run other commands via shell commands (run unit tests or clear caches). The added benefit of this approach is that deployments are tracked in git and can be rolled back easily.
Script based approach
Similar to a git deployment, a script based approach can be used for deployment to staging and production sites. This approach relies more heavily on POSIX shell commands (like rysnc, grep and diff). This requires more up front work for deployment, but is much more customizable and ultimately powerful. A combination of a script based approach and git deployment are common in the WordPress and Drupal worlds for deployment.
A more robust build system can also be implemented. In a CI type environment, a combination of unit tests, code review, VCS and deployment can all be rolled into one. More robust and powerful than a script based approach, a CI deployment plan is almost bulletproof as most (Travis CI, Jenkins) mandate testing of code before passing a build. This approach requires the setup of a dedicated CI server that has hooks into the VCS (git, svn etc.) and still requires the integration of shell scripts to fully take advantage of.
More than scripts but less that full-fledged CI systems are some tools that can be used to deploy and sync WordPress and Drupal sites.
Capistrano is a Ruby based tool that became popular with the Ruby on Rails crowd as a way to deploy code. Similar to a git deployment process, Capistrano allows for command line deploys and post deploy hooks but allows for a robust roll-back feature. Capistrano is configured via config files and has a requirement that both host and target are running Ruby.
Drush is the Drupal-shell that allows for running command line scripts specifically on a Drupal codebase. Many things like installing modules, setting up sites and themes, basic database versioning to basic deployment via rsync, can be accomplished by Drush.
Another tool similar to Drush is wp-cli. A super powerful command line tool for managing WordPress, wp-cli does for WordPress what Drush does for Drupal. Custom commands can also be written to hook into custom code, themes and plugins. Cool.
Just switched this blog over to a self hosted Digital Ocean VM. I was able to migrate all of my content away from WordPress.com, which was nice. Testing out some Cloudflare DNS and Nginx action.
This site is going to be a playground for new tech and fun code. Stay tuned!