1 trick I use to keep my LinkedIn contact list clean

I try to keep my LinkedIn contact list as clean as possible. Quite frequently I’m getting invitations to connect from people I don’t know, and with whom I don’t share much. Most of the times they are recruiters/sourcers who are only interested in building a large list of connections. They don’t even bother writing a line after I accept the invitation.

Here is my procedure to reduce noise in my contact list

Step 1: accept the invitation

Yes! Just accept the invitation. You don’t know if that person is really interested, or just scouting. After you connect, open the profile of that person, and click on the “Tag” in the relationship section.

linkedin_relationship

How to tag a contact

 

Step 2: tag the new contact as ready_to_trash

This tag is rather self explanatory!

 

Step 3: periodical clean up

Once every couple months, I filter all my contacts tagged as ready_to_trash ( My network > connection , then in the Filter by chose Tag, and pick the ready_to_trash tag).

I then go one by one, and check the interaction with that contact. If there was no activity at all for a month (heck, even a week) , I delete the contact from my list.

linkedin_3_months_nothing

3 months in my contact list…not even a short “thank you for accepting my invitation”

Some of those contacts will come back. After all, if you got on their radar once, you’re likely to become their target again in the near future!

how to create an alert in host-tracker

This short how-to will get you started with HostTracker, a simple but effective way to monitor the health of your web site

Step 1: Add a “contact”

This is the notification channel. I used “email” , but you can have SMS, Viber, Skype, or even HTTP Posts, to handle the notification with your own web service.

Step 2: Add a “check”

To check that a web page is up, use a “web site check (http)”. In the basic options you will define the URL of your site, and the interval of the checks.

Step 3: Advanced options – Content check

In the advanced options, you have the field “content check”. Make sure to use it to verify that the page you’re GETting contains some string that is expected in the live version of the page. This will verify that the site is behaving as expected. Some malfunctioning might result in some error page, that still looks like a valid response to an automated life check. If you look for a specific piece of content, your level of confidence in the check will be higher.

Step 4: Advanced options – Preferred region

HostTracker is great: it lets you decide from which region your requests should be executed. You should pick the regions that are closes to your target audience. If you have a global audience, I suggest you pick the region closest to the datacenter that hosts the site.

Step 5: intentionally take down your site (optional)

If you have the luxury of taking down the site without hurting your audience (before launching the site, or as a “scheduled maintenance”) , you will be able to actually verify that the notifications are getting to the right place.

If you don’t have this luxury, go back to step 3 and add an incorrect content check. This will result in a failed check, and subsequent notification.

how to write a JMeter test

In this how-to I will explain how to write a simple HTTP GET test with JMeter, that can be used to measure the responsiveness of a web site.

Step 1: Download JMeter

JMeter (an Apache project) requires Java to run. Once downloaded and unpacked, you can execute the UI by running jmeter.bat (windows) or jmeter.sh (linux) in the bin folder.

Step 2: Add thread group

Set the “number of threads” to the number of users you want to simulate. I will use 10. I will leave the ramp-up time to 1 second, and the loop to 1.

jmeter_add_thread_group

Step 3: Add HTTP Request sampler

Right click the thread group you created in step 2, add >> sampler >> http request.

This object will define the actual HTTP request that you want to test, simulating the number of concurrent users defined in step 2.

jmeter_add_http_sampler

Step 4: Add an Aggregate Report listener

Again right click the thread group you created in step 2, add >> listener >> aggregated report

This object will show you the result of your test. Changing the number of concurrent users and the ramp up time, you will get different results in the report. Keep an eye on the 90% 95% and 99% lines. These will give you a good idea of how responsive your site will be under load.

jmeter_results

Step 5: multiple pages

To test multiple pages in the same site, you will need to add more HTTP Request sampler. Those sampler will share the same root address. To avoid having to type the same common configuration in each HTTP Request sampler, add a “HTTP Request defaults” config element. Right click on the Thread Group create in step 2, add >> Config Element >> Http Request Defaults.

This is particularly helpful if you have a test environment and a production environment, and the only difference between the 2 is the root of the address. With a config element you won’t need to change all the HTTP Request listeners

Step 6: add assertions

Suppose you want to verify that a piece of the response is actually contained in the page under test. Right click one of your HTTP Request sampler, add >> assertions >> Response Assertion. In the object screen, you can add a “Pattern to test” .

To verify that the assertions don’t fail, you will need to add an Assertion Results listener to the HTTP Request sampler, checking the “Log/Display Only” “errors”.

 

how to deploy WordPress on Windows Azure using Docker

Step 1: Create a VM on Azure

In portal.azure.com click the “+ new” icon at the top of the left toolbox, and choose the CoreOS Linux (Stable) image.

CoreOS VM image

Create the VM using the Resource Manager wizard. I prefer to use an SSH key instead of a weak username + password. Find the IP address of your newly created VM, you will find it in the Properties tab of your VM object

Step 2: SSH into the VM 

On Windows I use PuTTY. This will give you a shell into your CoreOS machine.

Step 3: create the docker-compose yml file

The official WordPress Docker image documentation contains an example of yml file to start a MariaDB (MySql) container and a WordPress container, linked together, with passwords already configured.

Execute these commands

  1. touch docker-compose.yml
  2. vim docker-compose.yml

Now paste the content of the yml that you can find in the documentation, and “save and exit” from vim using :wq

Step 4: install docker-compose

just run this command to download the executable, and change its permission
curl -L `curl -s https://api.github.com/repos/docker/compose/releases/latest | jq -r '.assets[].browser_download_url | select(contains("Linux") and contains("x86_64"))'` > /opt/bin/docker-compose
chmod +x ~/docker-compose

Step 5: run docker-compose

run this command to “compose” your containerized wordpress deployment. This will download the docker images of MariaDB and WordPress, will spin 2 configured containers, and link them together.

sudo ./docker-compose up -d

Step 6: open port 8080 on your VM

By default, you can only use port 22 to SSH into your VM. To be able to browse your WordPress site, you need to open the configuration of the “Network security group”, and create a new “inbound security rule” to allow all traffic to port 8080.

You probably want your WP site on port 80. To achieve this, in the yml file change 8080:80 to just 80:80 . This will map the port 80 of the container to the port 80 of the host.

Step 7: browse your newly created instance

Using the IPaddress of your VM on Azure, and the port defined on step 6, you can access the site you just launched!

Congrats 🙂