CL-SQL fun with wordnet

November 27th, 2009

Common Lisp surprises me more and more each and every day. I never thought of using it for SQL interaction, but the adventures of CL-SQL for my linguistics class lately really opened my eyes.

CL-SQL is an ORM, like that of ActiveRecord, Django’s ORM, and so on. It leans a little more toward the SQL Alchemy side of things, though. I will likely provide a much more detailed tutorial later once I get a general understanding of this library – but for now I’ll provide a bit for links on where to find more information:

CLSQL Main Site: http://clsql.b9.com/
Script I learned a lot from: http://www.boundp.net/files/weblog.lisp
Github post of my wordnet stuff: http://gist.github.com/244360

Now for a bit of information about wordnet. I’m currently in a computational linguistics course at the university, and part of the class is to develop a project of sorts. Mine relates to the use of wordnet, which is a fairly complicated database. Basically, wordnet was developed by Princeton, that has a fairly large set of words and their definitions, synonyms, hypernyms, hyponyms, and so on. In sort, it shows a lot of ways that one word relates to another word in various ways. I found a web site that had the MSSQL files for Wordnet, which I downloaded and attached. Along with that, a number of example view code that I modified to add to a listing of views. Since I do my development, most of the time, on Linux – I decided to get ODBC setup to the MSSQL server. CL-SQL works beautifully with this setup. The gist above shows the details.

For the SQL Server database I got, you can view the information here: http://opensource.ebswift.com/WordNetSQLServer/

I will likely provide more information as I go with this, as I’m finding wordnet more and more fun to mess with.

Iowa Code Camp – Nov09

November 7th, 2009

I finished my presentation for Iowa Code Camp this morning – it went pretty well I feel, although a very little turnout. Here are my notes and other information!

Here are some download locations for my notes and my code itself:

Sides themselves:
http://static.thedarktrumpet.com/theory-iccn09.pdf

Code:
http://static.thedarktrumpet.com/code-iccn09.lisp

Twitter, Facebook, Github, oh noes!

October 18th, 2009

I’ve been into these services for awhile, but have done a fairly poor job of communicating these from this site.

So for some of my tech-related comments, especially that of Common Lisp, Twitter is a good source:

http://twitter.com/TheDarkTrumpet

For more personal stuff, I tend to use Facebook (although VERY little)

http://www.facebook.com/dthole

For code that I’m releasing publicly github tends to be the better spot, at the moment, for that:

http://github.com/TheDarkTrumpet

Coders at Work: A Review

September 7th, 2009

About a year ago, I decided to ask a number of people what I should read, and what I should do to be a better programmer. Over the next year I spent a lot of time with these same people trying to learn how to be a better programmer. This book, Coders at Work, is one of those books which turns out to be one of the most helpful programmer-guides I’ve come across.

- Structure of the book:

At the start of each “chapter” (which is really an interview), there’s a short description about who each individual is. From there the chapter continues with a basic “interview-style” format, where Peter asks a question, and the interviewee answers it. Usually there’s a followup question to clarify the previous answer – which has both the positive and negative effects to say “Person A answered this way, person B answered this way” – so in other words, at times it’s hard to say, for example, how Zanwinski’s answer differed from Peyton’s.

The first question asked is one very crucial for most people, though, which is more or less, “How did you get into this?”

- Topics Covered:

The topics covered is not specific to only coding – some of the topics include:

  • How did one get into coding?
  • What were some successful projects?
  • What were some less-successful/failure projects and why?
  • What type of education is useful (e.g. is a PhD useful?)
  • What tools does one use and why?
  • What does one enjoy about programming?
  • How one works with others and the dynamic of that.

This book is not only about coding though! That’s an important thing to recognize about this book – it’s leaned a bit toward programmers in general, but these topics help to make a better programmer in general – not simply specific to just coding better.

Some of the topics discussed feels a little dated, with some technology that’s being discussed well before I was born, but since many of these challenges exist as timeless and I see in my everyday life, they are still valuable to hear about.

- Likes:

The main thing I enjoyed about this book was the fact that it’s extremely applicable to what I see each day. A perfect example was the very first chapter in talking with Zanwinski. In this chapter, he discusses the concept of “Worse is Better”, and how the strive for perfection caused a company to fail. This very concept rings extremely clear to me, in I’ve seen a system that was developed in the “Worse is Better” philosophy, and the development of the current system has seen times where the “Right Way” caused huge delays in the development of the system. It was a breath of fresh air to hear someone else discuss a situation that was really close to one that I’ve been, and in some ways continue to be, in. This is the main thing that I feel I enjoyed about the book itself.

Another applicable thing I read was the reasons for getting a PhD – which I’ve been contemplating for well over a year now. To hear perspectives about the reasoning to get or avoid one helps a lot in the contemplation.

Along with that, the topics were very interesting – and many of the answers were very clear and to the point. One can tell that these words were exactly the way the person said it – and not edited. This is a great feature because it feels more like a dialog than just a story-telling session.

- Dislikes:

There are a few areas of the book that I feel could have been done a bit better.

  • When describing more old technology (e.g. the computer that Peyton learned on), I felt I had no clue what this device looked like or anything. A quick google can help in a lot of these situations, but there’s a certain disconnect from the book itself as one’s reading. This can happen especially for younger developers who haven’t heard of some of this technology.
  • The rants on some of the languages (e.g. Perl) can be taken poorly by some. I found it kinda funny, and it’s clear that it’s the individual’s opinion, but I can see some people being annoyed by that. There’s not a lot that can be done about this besides cutting out content.
  • Better identifying similar crucial questions that are asked to each individual would be helpful to hear the ideals that are different between each person. Those, with a special icon or something, would have been very helpful for comparing and contrasting differences.

- Summary:

Overall, I feel this book is quite good, a definite 4.5/5 stars. This book gives a “mentor feeling”, when I honestly don’t have a mentor at this point at my job. I found that many of the questions in this book provided insights into the difficulties I’m currently presented with, and offers suggestions on how to approach them. While this book will likely not be the totally definitive guide for all programming-related knowledge, it’s definitely something I feel fits in a niche that currently isn’t occupied by other books. I feel this will benefit all levels of programmers.

TDD or “Test after Writing”?

July 26th, 2009

I’m sure most that are reading this already know what TDD stands for, but to those that don’t know it’s termed as:

Test Driven Development

The basic idea is somple. When you write your code, you – well, don’t – you write the test first, then write the code. There are a few reasons for this:

  • Code is better guaranteed to be covered.
  • You can think through your problem, as you’re writing it.

TDD works great and all, if you really know what you’re working on – what the end project is going to be, and have the general design built. Many people, including myself, want to see more immediate results rather than spending time writing tests first.

As I was writing my Common Lisp library for interfacing with git (will provide links later), I wanted to write unit tests for my code. I feel that writing the tests before the code would have not worked. There’s just little/no way for me to really know the structure given my current experience and understanding of Lisp in general. Waiting until the end of the library to write tests would also be equally stupid, because that’s a lot of time invested and likely full rewrites needed to help make code testable.

The area I’m advocating at this point is a “middle ground” to the two testing methods. I found for the Lisp library, that I could do this pretty simply by thinking of:

  • What are my chunks of functionality?
  • Are my functions doing one and only one thing (really well?)

For each chunk then, what I’ve been doing is the following iterative development:

  • Write the code first
  • Start writing tests for the fuctionality (denoted by comments if needed)
  • Writing one test for each function.

What this has done for me is allowed me to think of my code in a smaller scale – each node of functionality has a testable purpose now. So my iterative development has been something like:

  • Write code
  • Write test for the code
  • Rewrite code to be more testable (usually if a test has more than one assert in it or a totally different assert than what’s necessary)
  • Write tests for the new split-out code (basically just split out what I was testing before)
  • Rewrite code again to make it more testable

…etc, etc until it’s “good enough”

I found that this helps me with great code coverage without forcing me to really go full TDD – which is really hard to grasp. It may be worth trying for some others who want to improve testing but don’t feel the jump to TDD is really in their grasp.

Get Adobe Flash playerPlugin by wpburn.com wordpress themes