Joe Letizia

22 Jun 2014

For close to a year, I had been working to find, and being employed in, my first true '9-5' software development job. It was an incredible experience and one that I'll never forget. The process of landing my first job was one of the hardest things I've had to do. Actually working at the job has been even harder, but so incredibly rewarding that I wanted to share my experiences in order to help more people gain employment in software development.

It's not Personal : It's Business

Being a junior developer is hard. The profession is difficult on its own, but if you also consider that many software development shops have brutally honest performance feedback schemes, it can seem that no one is truly cut out to be a software developer. This is obviously not the case. Hearing where you need work and what you're lacking is tough on anybody. Learning how to embrace the feedback and not looking at it as a personal attack is essential, and a key sign that you are willing and able to grow personaly and professionaly.

You will receive tons of feeback as you begin to interview for your first position. Every offer and rejection you receive will help mold you into a better developer. Any and all feeback is important; remember it. A good tactic is to keep a record of all of your interviews. Use a google docs spreadsheet to record things like:

• Date
• Company name
• Interviewer names
• Interview format (white board, pairing, puzzles)
• Impressions on the company process both positive and negative
• Culture
• Offer details should it go well
• Feedback received from interviewers

Embrace your CS Fundamentals

The first key to becoming a developer is landing a job. For most, the route generally begins with your first job out of college. Thus begins the discussion on the dreaded programming interview. Some companies have ridiculous puzzles about finding a close approximation of how many grains of sand are on the Earth (you probably don't want to work here), other companies will ask you questions about data-structures and algorithms and have you sketch out solutions on a whiteboard, while others will sit you down next to a team member and work on a project out of their backlog. Regardless of how the interview is done, the one constant through all of them is that they will require fundamental Computer Scienece knowledge. Things like basic data structures and algorithms and object oriented design are essential in most interviews.

For a junior position, places outside of Google and Facebook aren't going to probe you for concepts that you didn't learn in school. However, you'll certainly want to be able to explain in what situations a certain data structure is more advantageous over another.

I've been shopping around for data structures books for a few months. It seems that there is almost a unanimous consensus for Introduction to Algorithms(also known as the CLRS after the authors) to be the de facto standard. To this point, I find myself to be in agreement with those that gave it such high praise. A general understanding of all the points in the text should be a great stepping stone for even seasoned developers.

Attitude is Everything

The attitude with which you approach your position is (at some companies) more important than the state of your current skill set. If you are difficult to work with, have an abrasive personality, or are in some other way incapable of being a part of a team, your skill set can be inconsequential. There are many well regarded engineers out there that are known as "The Brilliant Jerk." These engineers are obviously very highly touted for their ability. But working with them can be insufferable. Don't be a brilliant jerk.

Don't be affraid of not being the best developer on your team. The people I work with code circles around me on a daily basis. However, you can still be a contributing member of a team as long as you have a good attitude and are continually progressing.

Interviewing

On my current team, we use a somewhat unique approach to interviewing. It's strikingly simple… but the fact remains that it is unique none-the-less. We simply invite candidates that pass a phone screen to complete a simple pair programming exercise with one of our developers using test-driven-development. There are no tricks, no riddles, and no counting grains of sand. This gives us a few key points:

1. Whether or not they have enough of a background in data structures and algorithms.
2. Whether or not they personable enough to work in a team to accomplish a common task.
3. A small look into their thought process and how they vocalize their thoughts.

We tend to keep it to an hour in order to save the candidate time because the next round is a full day of pairing with 2-3 of our developers. The interview is tagging along with your partner and tackling real features out of our backlog. This process is as much a technical assessment as it is a deep dive into the candidates attitude. Having an inquisitive personality, a calm yet up beat demeanor, and even a sense of humor are all things that employers are looking for in their junior hires. If this sounds a bit like blind dating, you're not too far off. This doesn't mean that you shouldn't be assertive, however. One thing that may help people stand out is having a set of opinions on best practices that you've developed over the course of your experience. Being able to express these opinions in a way that is both assertive and well mannered is a great combination. By doing that, you've shown that you not only have good skills, but can be a great teammate.

Write Some Code

Most universities do a fine job teaching theoretical Computer Science. A good base in Computer Science is essential in your professional career. However, being introduced to the more practical problems you will see in your day-to-day professional career is also essential. A great way to do that is to have a side project. Apply what you are learning in your classes to something that you can get behind. If you are into finance, write a small application that does some analysis on several securities to find correlations. If you find you have an interest in gaming, create a few graphics programs in OpenGL. If you are passionate about web development, create a web application to handle your personal blog. There are many things that you can apply your course work to while at the same time learning the necessary tools that make up our trade as software developers.

In any non-trivial project you will want to set up a version control system which will allow you to track the changes you make to your code as you add more and more features to your project. Git + GitHub is a pefect choice for this. GitHub allows you to share your code with others if you desire, access your repository from many machines, and uses git under the hood which has become quite prevalent in the version control systems market.

Learn to Interview

Interviewing is like writing code, playing soccer, or riding a bicycle; they all take practice to become proficient. Once you have some experience under your belt, take a stab at applying to a few companies. Make sure to have your resume or other application material looked over by a friend. Remember that side project you did? List it! Put a link to your github on your resume! If you spent a significant amount of time on it and you can explain the strengths and weaknesses of the code you wrote eloquently, you are way ahead of the game.

Your first few interviews will most likely not go well. You will probably get flustered when asked to whiteboard code or pair program. This is fine, it takes some getting used to. After a while, you'll learn how to use the appropriate amount of space on the white board, how to elegantly state why you are using one algorithm or data structure over another, and how to present yourself as a overall well adjusted human being.

At many companies, writing some code on a white board is still the go to medium for interviews. I would definitely encourage an interviewee to practice before going into an interview that was certainly going to be on a white board. It is so different than being behind a keyboard.

• Make sure your writing is well spaced.
• Keep your handwriting size in check if it is too big.
• Don't drift up or down when writing long lines.
• Use a fine tip marker (bring your own).
• Rehearse.

Post-interview: Success!

Congratulations! You made it! It only gets harder, but much more rewarding from here. There are several key points to succeeding as a developer that you should pay extra attention to.

You Will Fail Often

For many, this is the first time others will see the code you write on a frequent basis. It is undoubtedly not going to be up to the standard of a professional software engineer. It's very rare to see someone straight out of college or in the their first job writing elegant code. However, do not let that break your will. If you are on a good team that knows how to mold someone they've seen potential in, you should break those bad habits quite quickly. Keep your mind open to the opinions of your more senior peers. They are bound to have been through the problems you've been through. Your senior peers will most likely have great feedback on how to structure your code and how to be more succinct and elegant in the particular languages and frameworks your project employs.

Process Before Domain

Software Engineering isn't much different from other disciplines of engineering in the fact that they all employ a standard operating procedure that is crafted over a long period of time, and generally not deviated from. Creating and iterating on that process is as important as the code you're writing. Therefore, I advise junior people to focus on learning your team's process before trying to become versed in a particular section of the code base or the business domain at large. It may seem tempting to be able to answer questions about a particular bug that your teammate is investigating, or know some obscure detail of the business domaain, but a deep rooted knowledge of the engineering process is much more valuable at this stage in your development. Know your process, and the rest will fall into place.

A team's process might include some of the things below.

• Version control
  • What VCS does your team use?
  • How does your team handle feature branching?
  • How do you integrate changes into the main line?
• Deployment
  • Is deployment automated?
  • What scripts need to be run to push a build to an external environment?
  • How do the stakeholders approve a build?
• Code review / pair rotation
  • How do I approach my peers for feedback?
  • How often should I ask for help on an assignment?
  • How can I improve my soft skills for working with teammates?
• Iteration planning with the stakeholders
  • How does the team estimate a body of work?
  • How does that effect the stakeholders' prioritization of certain features?
  • How do I know when to push back on implementing a feature?
  • How do I advise other teams of what is feasible for the engineering team?
• Continuous integration strategy and how it relates to deployment
  • Does a build that passes the test suite automatically get pushed to an environment?
  • How does your CI system work? (Location, typical settings)
• How to test
  • Unit testing
    • Mocking and stubbing.
    • How to notice smelly code via a test.
    • How to write a valuable test.
    • How to isolate your code from external dependencies.
  • Integration testing
    • What framework does the project use?
    • Should I create database records in every test (factories) or do we use fixtures?
    • How do I stub external dependencies and third party services?

All of these facets of your team's process are what make up the majority of what will be your area of expertise. I never really understood that until a few months into my first real engineering job. The best way it was illustrated to me was by one of our senior consultants. He knew I happened to enjoy martial arts. My friend explained to me that this knowledge was the basis of your repetoire, and you should fall back to it when you find yourself struggling; do your katas. In martial arts, katas are forms or drills that exemplify the basic mechanics of your art. It's typical to focus on these katas whenever you find yourself struggling or moving into non-trivial or improvisational aspects of your craft. Software is no different. Relying on your fundamentals is what will allow you to succeed.

Embrace Feedback

In order to succeed in your new team, you have to learn to trust it's members. Try to strike a relationship with one of the more senior people on your team. If you can, grab a coffee with them periodically to see if there's anything you may need to work on. If you have questions about a part of the code, a new pattern, or something else you don't understand, ask! One of the greatest aspects of surrounding yourself with a good team is that you will receive feedback on where you need work. This will increase the rate at which you improve your skills exponentially.

Embracing feedback also includes knowing where you went wrong. If you do find yourself not understanding a concept or if you made a mistake on a project, accept that fact, admit it to yourself and your colleagues, and improve on that weakness. This shows your dedication to the project and team, as well as your ability to improve. If I could sum up what it meant to be a junior developer in one sentence, it would be "A developer who improves everyday." In that respect, all developers could be considered junior in some aspect, but beginners gain distinction via the velocity at which they improve. If you can show an ability to pick concepts up quickly and consistently, you are ahead of the game.

22 Apr 2014

When I write code, I sometimes find myself doing something that I don't really understand. A lot of times, those things tend to be language constructs that I somewhat take for granted. I think we all can be guilty of this sometimes. It's not necessarilly bad, but understanding it is certainly better than not.

One thing that I use all the time, but didn't question until recently is below.

strings = ["hello", "my", "name", "is", "joe"]

  upcase_strings = strings.map(&:upcase) # ["HELLO", "MY", "NAME", "IS", "JOE"]

What is that ampersand (&) in my call to map doing for me? I had no idea up until I was driven to ask a friend that knew Ruby much better than I did. The ampersand is actually shorthand for calling to_proc on a symbol. But how does that work?

One thing we have to remember is that map actually takes a code block. Since that is the case, passing it a proc object will actually work. The following code is equivalent to the above:

upcase_strings = strings.map {|string| string.upcase} # ["HELLO", "MY", "NAME", "IS", "JOE"]

to_proc is smart enough here to understand that we want to call the method we're procifying on the object that is being passed to the block. map is simply passing each string literal object to the code block as it iterates through the collection.

It's nice to understand things that I did out of habit that I didn't truly understand before.

20 Mar 2014

Jasmine and RSpec are both test frameworks for JavaScript and Ruby respectively. While working on a web project in a test driven environment, you're sure to run into both a lot; RSpec more so if you work on primarilly back end code, but a full stack developer is expected to know both.

Jasmine and RSpec have different ways of accomplishing essentially the same things, particularly mocks and stubs. This article is a simple example of those differences.

RSpec

RSpec accomplishes stubbing and mocking via two different but related methods, #stub and #double.

#double is used to create a mock object. This mock can be used as a directly passed collaborator to a method you are testing, or you can have this double be returned by a collaborator within the method you are testing.

A double is typically created in the following fashion

describe ClassUnderTest do
  describe "#method_to_test" do
    let(:mock_object) { double(:mock_object) }

    it "this is my test" do
      ...
    end
  end
end

#stub is used to override the behavior of a method by replacing its definition and simply returning a predetermined value. This is useful when you want to simply assert that a method is called on a collaborator, or to have that collaborator return a planned value.

Generally, you can stub methods on mocks in order to guide your code under test down a specific path in order to test that it works properly.

#stub is used in the following fashion.

describe ClassUnderTest do
  describe "#method_to_test" do
    let(:mock_object) { double(:mock_object) }

    before do 
      mock_object.stub(:method_1).and_return(5)
    end

    it "this is my test" do
      mock_object.method_1.should == 5
    end
  end
end

This can also be accomplished via:

describe ClassUnderTest do
  describe "#method_to_test" do
    let(:mock_object) { double(:mock_object, method_1: 5) }

    it "this is my test" do
      mock_object.method_1.should == 5
    end
  end
end

The second example sets the return value of method_1 on mock_object to 5. Both the second example and the third example are relatively the same. It is a matter of preference.

As well as stubbing return values from methods on mocked collaborators, you can assert that a particular method was called on the double in the following way.

describe ClassUnderTest do
  describe "#method_to_test" do
    let(:mock_object) { double(:mock_object) }

    it "this is my test" do
      mock_object.should_receive(:method_1)
      ClassUnderTest.new.method_to_test
    end
  end
end

One thing to note, the #should_receive method creates an implicit stub on the method. If this method is tested more than once, you would be well advised to do the following:

describe ClassUnderTest do
  describe "#method_to_test" do
    let(:mock_object) { double(:mock_object) }

    before do
      mock_object.stub(:method_1)
    end

    it "this is my test" do
      ClassUnderTest.new.method_to_test
      mock_object.should have_received(:method_1)
    end
  end
end

Another nice scenario for stubbing is to stub conditional values to direct logic flow in your method under test. Take the following method for example:

class ClassUnderTest
  def initialize(checker)
    @checker = checker
  end

  def method_to_test
    if checker.do_something
      "it was truthy"
    else
      "it was falsy"
    end
  end
end

describe ClassUnderTest do
  describe "#method_to_test" do
    let(:checker) { double(:checker, do_something: do_something_value}

    context "when the checker returns true" do
      let(:do_something_value) { true }

      it "returns 'it was truthy'" do
        ClassUnderTest.new(checker).method_to_test.should == "it was truthy"
      end
    end

    context "when the checker returns false" do
      let(:do_something_value) { false }

      it "returns 'it was falsy'" do
        ClassUnderTest.new(checker).method_to_test.should == "it was falsy"
      end
    end
  end
end

Since we have stubed checker.do_something to return true or false in different contexts, we can verify the return value of the method method_to_test.

Jasmine

Jasmine accomplishes stubbing and mocking via similar means. The typical stub method in Jasmine is spyOn. spyOn can be called on any object to stub out methods on that object. The stubbed method will not execute the implementation code, which is one of the main points of stubbing. In the case below, an alert will not be raised since the method is stubbed.

describe("object-under-test", function() { 
  var spy, object;

  beforeEach(function(){
    object = {
      methodToTest: function(){ alert("hello"); }
    };

    spy = spyOn(object, "alert");
  });

  it("this is a test", function(){
    object.alert();
    expect(spy).toHaveBeenCalled();
  });
});

In order to create a mock, analogous to a double in RSpec, one would do the following:

describe("class-under-test", function() { 
  var mock, object;

  beforeEach(function(){
    object = {
      methodToTest: function(collaborator){ collaborator.methodToWatch("hello"); }
    };

    mock = jasmine.createSpyObj("nameOfSpy", ["methodToWatch"]);
  });

  it("this is a test", function(){
    object.methodToTest(mock);
    expect(mock.methodToWatch).toHaveBeenCalledWith("hello");
  });
});

This is similar and different from RSpec in a few ways.

• Similarities

  • The method being stubbed does not call through to the original declaration of the method.
  • Injecting a mock into an object under test in both frameworks allows you to assert that a method was called on that mock.

• Differences

  • In Jasmine, spyOn is called independent of the method you are stubbing, not directly on the object like in RSpec.
  • The expectation toHaveBeenCalled is checked after the invocation of the method. This has since been added in RSpec but legacy RSpecs are full of expectations prior to invocation of the method under test.

13 Jan 2014

Consider the case where you wish to find records in a table, join those records to another table via a left join (all records of the original table, nulls for the non-matching records on the right) and only return all the rows that result in NULLs on the right hand side. In SQL, that would look something like this:

SELECT COUNT(*) 
FROM posts
  LEFT JOIN likes on posts.id = likes.post_id
 WHERE likes.id IS NULL

The above should be rather efficient, yes? It's idiomatic SQL and something you might find out of a standard undergrad textbook. However, consider the restriction added in the WHERE clause.

We've restricted against likes that have been joined in against posts via likes.post_id using the likes.id field. Even with proper indexing, once these tables have sizeable datasets, this query will take a significant amount of time. Why? I'm not really sure. My best guess is that since we are restricting against likes.id rather than the field we used in our join clause (likes.post_id), the psql query optimizer has to go back into the joined table, bring in the likes.id field, and restrict. Amending our query to the following showed a significant performance increase:

SELECT COUNT(*) 
FROM posts
  LEFT JOIN likes on posts.id = likes.post_id
 WHERE likes.post_id IS NULL

In my case, I had a performance improvement from this query taking 7 seconds originally, to ~50 milliseconds after being corrected. My pair for the day and I were both incredibly surprised by this, but we'll certainly take the improvement.

14 Nov 2013

Many times when working with user input, you won't necessarily want to display the entire string if it is over a certain length. Let's say I allow my users to set their company name:

"Kirk, McCoy, Chekov & Associates Law Firm of New Jersey"

If I wanted to display this text in a grid view, this may be significantly more text than I want to display. To deal with that, we can truncate the string on presentation. A fair way to do this is to display a set of characters to denote that a string has been truncated so that the user doesn't get worried that their data has been manipulated unexpectedly. A nice demarkation of that is the ellipsis (…).

Rails comes with this functionality built into ActiveSupport.

company_name = "Kirk, McCoy, Chekov & Associates Law Firm of New Jersey"
company_name.truncate(15) 
# => "Kirk, McCoy, Chekov & Assoc..."

I ran into a weird bug with this method the other night. I wasn't actually trying to use #truncate this way, but I was certainly surprised by the behavior. Calling #truncate with a length less than the length of your omission (ellipsis by default) yields some unexpected results.

company_name.truncate(2) 
# => "Kirk, McCoy, Chekov & Associates Law Firm of New Jerse..."

Huh?! What's going on here? I was a bit surprised by this, so my pair and I pulled up the code for the #truncate method, seen below.

def truncate(truncate_at, options = {})
  return dup unless length > truncate_at

  options[:omission] ||= '...'
  length_with_room_for_omission = truncate_at - options[:omission].length
  stop = if options[:separator]
    rindex(options[:separator], length_with_room_for_omission) || length_with_room_for_omission
  else
    length_with_room_for_omission
  end

  "#{self[0...stop]}#{options[:omission]}"
end

The key part to note here is the calculation of length_with_room_for_omission. Since the ellipsis is a 3 character string, passing a value of 2 for truncate_at will result in a negative number. Ruby has a property for arrays known as negative indexing. In many other languages (C#, Java, C), passing in a negative value as an index to an array results in some kind of indexing error/exception. However, in Ruby, negative values will wrap around the end of the string.

"hello"[-2]
# => "l"

So, passing stop as an index to the range for the string index results in the string wrapping around.

07 Nov 2013

I'm currently working on a large scale ETL (extract, transform, load) project. We have a legacy source data model that, in certain areas, vastly differs from the new generation destination data model. We lean on ruby to do much of this work since we are most comfortable working with ActiveRecord as our ORM.

One thing that we do for our acceptance criteria is take a count out of the old system for the records we are extracting, manipulate that count to account for any transformations we do in the ETL task that may increase or decrease the number of records, and compare that to the number of records we actually load into the new database. This simply gives us an extra data point to see if we have screwed anything up.

One thing we have begun to rely heavily on is the concept of Common Table Expressions in our count scripts in order to silo responsibility of our joins. For example:

active_groups as (
    select id 
    from groups 
    where status = 'ACTIVE'
  ),

  active_players as (
    select id
    from players
    where status = 'ACTIVE' and test is false
  )

What we have above are two separate queries that contain what is, in essence, a subset of all the records in their respective tables. These sets have been restricted prior to being joined into any related tables, like below:

active_groups as (
  select g.id, g.location, g.startdate
  from games g
  join active_groups ag
    on ag.id = g.group_id
  join active_players ap
    on ap.group_id = ag.id

This does several things:

1. Aesthetically, this is a bit easier to read. Similar to breaking out a class into logical methods like you would do in Ruby, this allows the reader to know what exactly your CTE is bringing to the table. It is properly named, and is very clear.
2. These CTEs will be run before their results are joined into the regular query. These CTEs have already been restricted via their respective where clauses, alleviating the regular query of that responsibility.

Recently, we've seen a great performance increase by using CTEs. Perhaps this can be attributed to postgres' query optimizer not being able to restrict our join tables until the join had already happened, which seems to be the only difference between using several CTEs rather than a single query and many restrictive where predicates.

23 Sep 2013

I've been trying to get a library of code up and running. This way I can refer back to it over and over in order to churn out apps quickly. One thing that I wanted to accomplish was to have the ability to rename an application. Rails doesn't make this difficult per-se, but the application name that is used on creation is buried in many different places.

So, I wrote RailsRenamer. It's definitely a work in progress, but it should help me out every once in a while.

One thing that RailsRenamer doesn't consider are the application secrets and cookie names. I'll have to change that.

23 Apr 2013

I was recently working on a side project to create an RSS reader in Rails. Well, to be honest, it was more of a javascript application that simply consumed data from a rails service. You can checkout the project here.

One thing I had to do was send a unique identifier to the front end to identify the article to read. To do this, I encoded the URL text in base64. I thought this would work great...until I realized that the '/' character is in the base64 character set...shit.

But fear not...rails has a nice little function in ActiveSupport called parameterize that will format a string into a URL-safe string.

Checkout the gist

31 Aug 2012

I never did much JavaScript programming at my last job. We were primarilly a ASP.Net WebForms shop and basically did everything with postbacks. Not the most efficient way to handle a web app, but for the small scale we were on, it wasn't much of an issue to be round tripping all the time.

Now I've been trying to use JavaScript as much as possible and follow MVC paradigms. One of the huge advantages that JavaScript has is great library support, jQuery being at the forefront. jQuery encapsulates common functionality (along with a metric butt ton of other awesome stuff) such as AJAX, making it simple to make requests to the server asynchronously (dur...) to get data without doing a complete refresh of the page.

However, beware of executing jQuery AJAX requests across multiple domains. Lets imagine you have a web app sitting on a server somewhere. That application wishes to consume data from a web service you've hosted somewhere else in your environment. These two applications sit on different servers with different domain names.

If you request data from the web service via a jQuery AJAX call in your first web app (on the client side, obviously), you may run into an error mentioning Access-Control-Allow-Origin not being turned on. This is because the web server hosting your web service has not given the browser the go ahead to use CORS, or Cross Origin Resource Sharing.

To turn this on, you must add a header to the HTTP Response coming back from the webservice. That header is Access-Control-Allow-Origin: *. The star can be replaced by the specific domain if you wish for added security. Here is a nice little web resource I found here is a helpful start.

I spent an entire day trying to figure this out. Hopefully someone sees this and saves them self sometime.

03 Aug 2012

I never really gave teachers enough credit until I tried to pick up the craft myself. I remember teaching my first jiu jitsu class about 2 years ago. My instructor was hurt or on vacation and asked me to cover for him during the basic class. We weren't going over anything exciting. All the things he asked me to go over were things he had shown me 50 times before. I walked in thinking I would be fine. Hell, I was even cocky. "Why wouldn't they love me teaching?!?!"

I arrived a few minutes early, started going over the material in my head, stretched out ahead of the class as everyone was pouring in... We begin class with the first technique I was instructed to show. I remembered what I was supposed to show, but how to show it was escaping me. I never thought of all the little details I follow through with as I'm pulling anything off. I must have spent 30 seconds showing that first technique. The new people in class must have been looking at me as if I had just explained the Hiesenberg Uncertainty Principle to their elementary school children... and I knew it.

It really took a long time to get the feel of teaching. You have to realize that not everyone (i.e. no one) thinks like you do. As a teacher, it's your responsibility to put things on a simple level; every student needs their own section of a Rosetta Stone that you will be providing them.

Starting my own teaching gig outside of helping out my instructor is proving to be a challenge. Marketing, insurance, money... They're all kind of scary. But teaching people poorly? Nope.

03 Aug 2012

With the olympics on, I'm automatically gravitated to judo. Given that I'm a jiu-jitsu player, it's the closest thing we have to an olympic sport. You see some ground work that closely resembles what we do in BJJ, but there's significant differences. Compettition judo forces you to hunt for the submission/pin very quickly. The referees have a tendency to bring the fight back to standing if there is a momentary lapse in progression. I've always hated that, and I will never get over it. This is not to say that there's nothing wrong with competitive jiu-jitsu either. I think pulling guard without properly engaging is a complete waste of time as well, along with the minimal reward given to throws and takedowns.

This is what I hate about olympic judo...

My suggestion? Take the best of both sports and merge them together. I think grappling should always be about control, so submission will always be the preferred method of victory. But both sports have a lot to bring to the table. Below you will find a rough draft of the rules that I'd like to see in a competition environment.

Takedowns:

• Takedown to guard (double leg, single leg, etc), takedown to turtle position and spin behind: 1 pt
• Ippon throw (force, technique, and speed) to the back.
  • Land in a guard: 2 points
  • Land past guard and hold position: 3 points
• No guard pulling without engaging your opponent and maintaining the position.

These rules reward throwing and takedowns much better than the current BJJ rules, but don’t end the fight or penalize you the way judo currently does for leg attacks and things like that.

People will most likely lose their minds when they look at the last bullet. By no means do I think the guard is an inferior or bad position. However, I don’t like the idea of simply grabbing someone’s sleeve and dropping to my butt and starting to play open guard. If I’m on top, and someone does this to me, I should be able to disengage and force my opponent to stand back up. This kind of guard pulling should be banned. It serves no purpose.

On the other hand, if someone were to go for a throw like tomoe nage, end up on bottom and not get a successful throw but lock up a full guard, that is a perfectly fine entry into the guard. You brought your opponent to the mat, and prevented him from disengaging. I wouldn’t award points for it, but I wouldn’t penalize someone for it either. The thing I want to prevent is sitting to your butt with minimal control of your opponent.

I’ll take a second here to talk about sweeps. In the BJJ world, a sweep is a reversal that occurs from a guard. Therefore, going from side control on bottom to side control on top does not net any points for the grappler who reversed the positions. I think this is wrong. What the BJJ point system is doing is encouraging people to go back to the guard for defense. I can appreciate that, but why go back to the guard if I can power roll someone over? Also, why should I not be awarded for properly executing an upa and getting out of the mount? I’ve switched the positions and should be awarded. Therefore, sweeps, or what I would rather call reversals, should be looked at as a simple takedown and be awarded one point.

I would also love to see a mechanic that awards points for maintaining dominant control, similar to osae komi (pin). Not in the same sense that it ends a fight after a certain amount of time, but in the sense that you should be rewarded for maintaining a dominant position. This also gives the player on bottom a reason to escape. The mechanic will be similar to riding time in collegiate wrestling. Every minute, award the grappler on top one point. This forces the man on bottom to work for the escape, and also rewards the man on top for maintaining control.

In BJJ tournaments, you’re awarded advantage points for actions such as near submissions, sweeps, etc. They seem to be applied so arbitrarily from referee to referee that we see many people lose on advantage points when the match ends tied. Simple solution: get rid of them. Overtime is a perfectly fine way to settle a tie. Wrestling does it, judo does it, BJJ can do it. BJJ is a bit different in the fact that it shouldn’t be decided by a takedown, so a sudden death over time is rather inappropriate. But a standard 3 minute overtime followed by a referee’s decision is more than appropriate.

The only remaining area to address is positional advancement in BJJ tournaments. Passing the guard, mounting, and taking the back are all rewarded separately and handsomely in BJJ. Passing the guard, mounting, and taking the back in sequence leads to 11 points, a huge swing. This is to drive home the point that BJJ has a hierarchy of positions that the creators deemed as a position from which to end a fight. It’s a completely valid system, but I don’t believe it is obligatory for a sport environment. In a purely sport context, the mount is not intrinsically more dominant than side control. They may be more dominant positions from grappler to grappler however. What I mean by that is a person like Roger Gracie is much more dominant from the mount than side control, while someone like me is a lot better from side control than the mount. We shouldn’t be deciding what is more dominant via a point system. The point system should encourage ending the fight, not a hierarchy of positions. Maintaining dominance will still award you a time based score, but not a flat set of points for simply gaining a position. Therefore, there are no additional points awarded for moving from side control to mount or from the mount to the back. All are viewed as equals.

This is obviously a first draft. I haven’t poked too many holes in this but I’d love to get other peoples’ opinions. It’s hard to think of how matches would play out. The only apprehension I have is that people would stall when past the guard. I would love to see a few matches take place under these rules to get a sense of how people roll under them.

23 Jul 2012

I work on a project that implements a RESTful webAPI that allows users to interact with the system over HTTP to get data and update things...nothing special.

When getting my environment set up, I had a problem sending the API POSTs and DELETEs. I would always be returned a 405. Well, the short of it came down to the WebDAV module that IIS 7 had running. I uninstalled that and it worked like a charm; my requests are now going through successfully.

This is the article that helped me out.

Total wtf?? moment.

23 Jul 2012

I'm not against scripting or anything, but come on... I don't want to believe that I have to write a script that runs periodically to back up my MySql DB. There should be some way to do it automatically like in MS Sql Server. All of my googling and asking around has led me to believe that I do have to script it out. To do that, I wrote the following Powershell script to run nightly to back up a wiki that I have hosted at work.

$date = Get-Date

#where you want your backups to go
$FilePath = "\\YourServer\WikiBackUps\"

#PSDrive creates a drive that is local to the powershell instance
#I did this because I am storing my backups remotely in case the DB server decides to
#go all cocker spaniel and shit itself.
$Success = New-PSDrive -Name J -PSProvider FileSystem -Root $FilePath

if ($Success)
{
  #arbitrary drive name
  $root = "J:\"

  #get all of the .sql files in the directory
  $Files = Get-ChildItem $root -include *.sql

  #HACK: I can't figure out why, but PS errors when there is nothing in the directory...
  if ($Files.count -gt 0)
  {
    foreach ($file in $Files)
    {
      if ($file.LastWriteTime -lt $date.AddDays(-10))
      {
        Write-Host Deleting $file
        Remove-Item $file
      }
    }
  }
}
#point the script at mysqldump.exe which takes your back up
$exe = "D:\wamp\bin\mysql\mysql5.5.24\mysqldump.exe"

#format the file name
$fileName = $FilePath + " dbname_wiki.backup" + $date.ToString("yyyy-MM-ddHHmm") + ".sql"

#run the backup utility
& $exe -u root dbname_wiki --result-file $fileName[/sourcecode]

19 Jul 2012

I'd like to think I approach things with a certain amount of realism. I prided myself in being self-aware for as long as I can remember. Perhaps it started a bit too early. I vividly remember telling myself "Joe, baseball isn't your thing." at 13 years old. Maybe that was the catalyst to picking up wrestling...who knows? It's a double edged sword. I didn't particularly like baseball, but I don't know how I would feel if I knew one of my yet non-existent children gave up something they enjoyed only for the sake of knowing their flaws and accepting them.

On the other side of the coin, being self-aware has led me to believe I have a very good sense of needing to prepare for things. Jiu-jitsu tournament coming up? Great, eight weeks to get ready. I am by no means an avid competitor. I like to compete, but I'm more of an enthusiastic hobbyist. I've seen people jump into tournaments without proper preparation and just get slaughtered. Where did that get you? Yes, you got in there and tried to play with the big boys. But what can you really learn by going out on the mat and gassing halfway through your match and getting smashed? You might come out saying "I worked hard" during those four minutes, but you only worked hard for four minutes!

It extends to everything. I didn't apply to a job asking for three years C++ experience and a background in some obscure DBMS without at least doing some exercises and sample problems. I didn't fly out to California and compete in the world championships after deciding 3 weeks prior because I had a good week of training in my gym of 20 guys. And I certainly won't be buying a $500,000 house with 5% down.

In just about everything, the battle begins before the shots are fired. The invasion of Europe during WWII was as successful as it was because of the planning that came before it. War was declared in December of 1941, while the invasion took place in June of 1944. That's two and a half years! How many people today have the stamina to spend 8 weeks training and coming up with a game plan for what could possibly be a few minutes?

13 May 2012

My general workflow for git looks something like this:

• Think about what I want to do.
• Create a branch in git off master.
• Write really bad tests.
• Write really bad code.
• Check diffs to review what I did.
• Stage changes.
• Commit Changes.

I've been using git for about a year now, and I always accomplished checking my diff by doing git diff. I would then add my changes by generally doing git add . I was very pleased to learn of git add -p. -p will run through each diff that is eligible for staging and give you the option on whether to stage them individually. This kills two birds with one stone. I am running through my diffs, checking for anything I may have done incorrectly, and staging each diff individually, in case there is a block I do not want to commit.

Give it a try.