Google’s Project Shield

Google has a new service you can apply for, Project Shield. It utilizes their infrastructure to protect against DDOS attacks.

“Project Shield uses technology called a reverse proxy, which allows a webmaster to serve their site through Google infrastructure for free, providing a “shield” against would-be attackers. So far we’ve protected hundreds of news organizations and human rights websites that have faced attacks aimed at censoring free expression. By protecting these sites, we’ve helped to keep vital information online during elections, major crises and conflicts.”

Disabiling Auto-Configuration in Spring Boot

Spring Boot is fantastic for rapid enterprise application development. At some point, using and RAD framework, you get to a point where you want to disable some of the auto-configuration features in the application. With Spring Boot, you do this by specifying in an annotation, the configuration you wish to disable. Example:

public class Application implements CommandLineRunner {
…by specifying the RepositoryRestMvcAutoConfiguration class, I can turn off the feature. More documentation here:

Core Principles

I gave a talk about unit testing at a client recently, and I had these two random thoughts I wanted to share. There are a couple benefits to writing unit tests that are not quickly obvious, one, unit tests act as documentation for new developers. Good (and bad, I suppose) software stays around for a long time. You will not be the only developer working on the system. When I come on to an existing team, one of the first things I look at are the unit/integration tests. It gives me the most comprehensive interaction model as a user or developer.

Another thing unit tests help with is design. If your code has to be unit tested, that thought guides you to design loosely coupled and cohesive components. If your module/system/component is tightly (highly) coupled, than you have to do too much setup or configuration to even write a single test method, and possibly your unit tests become integration tests, and they will not run on your continuous integration server. If your code is not cohesive, then you end up writing multiple test classes for a single component.

If either of those cases are true, then you should revisit your design.

ASP.NET & JQuery example

Below is an example of how you have to reference a DIV within your asp file, to call a JQuery function.

<script type=”text/javascript”>

var $j = jQuery.noConflict();

$j(document).ready(function () {

$j(“#employee_info_showhide”).click(function () {





When the ASP file get’s compiled, each ID of each HTML component gets a unique identifier appended to the end of the name, so you can’t reference the ID’s directly, you have to tell the compiler to add the indentifier to your JavaScript as well with the   “#name” declaration.