CodeCall Programming Forum - Blogs - WingedPanther

Thoughts on being a moderator

WingedPanther — Sat, 11 Feb 2012 22:38:10 GMT

Dunno why I'm posting this one, but what the heck?

One of the things I've been doing for several years now is being a moderator for this site. Occasionally, someone will join who is eager to join the ranks of moderators. Other times, we grow enough where we need to add one or two more members to our ranks. Regardless, there seems to be no awareness that being a good moderator and being a good member of the forum are completely different things.

All of us joined this site for one reason: we love programming, and love the sense of community here. Some of us came with skills in place, some of us came to learn, but we come to share and learn. I came for C and C++. C++ is still my favorite language, even after learning so many other languages.

If I was here as a regular member, I would mainly hang out on the C/C++ forum, debugging code and helping people out. I still do some of that, but I have a different primary role. I glance at EVERY forum. I read some forums, glance at others, and browse here and there in more. I have no interest in VB, for example. I glance at it every time I'm here, because I have to look for moderated posts, spam, and whatever else might be around that I need to deal with. That's the part that gets me. Some people WANT to be a moderator, but don't seem to realize it is a responsibility, not just an honor.

Another thing that is goofy. I am NOT the best programmer on this site. For every language I know, I know at least one, and often several, member who is far better than I am. Despite that, being flagged as a moderator means I get random PMs from people who are convinced I must be some programming Guru to have this role. They don't seem to realize that we could hire five non-coders, who are clueless about coding, to be moderators, and do just as good a job. It takes good judgment, patience, and no coding skills at all. It's amazing that people looking to hire others don't even know what they're looking for.

Do I regret becoming a moderator? Nope. I just find it interesting how poorly understood it can be. By the way, we are blessed to have a great team of moderators. You guys do a great job.

Book Review: Java The Complete Reference, 7th Edition

WingedPanther — Sat, 03 Dec 2011 14:11:34 GMT

Welcome to a book I will never recommend to someone who wants to start learning how to program with Java: http://www.amazon.com/Java-Complete-...2920795&sr=1-2 . This books is a great example of how you will change the types of books you want for learning as you progress. Before you say, "great, he finally found a sucky book," please understand that it's very good. Let me explain.

When you start learning how to program, you need to learn several things from a programming book. You need to learn language syntax, you need to learn programming concepts, and you need to learn paradigm concepts. So, for Java, you would need to learn the syntax of Java, you would need to learn how to use loops, function calls, etc, and you would need to learn OOP, inheritance, etc. This book does NOT teach all of that. This book teaches Java, and how Java implements the other concepts. If you don't understand what a for loop is for, you don't want this book.

Now, let's say you have a few years of programming under your belt. You've done some GUI work in a couple languages, you can whip up a tic-tac-toe program in your sleep, and you have a basic understanding of data structures and memory management. This is the book for you. It has NO problems for you to work through. The assumption is you can dig those up all day long by yourself. What it does is explains how the language works, and what library classes are available, in great detail but with few examples. This is the book you grab when you need to look something up.

If you are starting to learn programming, and starting with Java, this will be about the third book you get, not the first, but you'll love it to pieces because it doesn't skip stuff for no reason. If you are already strong in C++ or C#, this is a great book to start learning Java with, because you'll get explanations of how Java differs from them.

It is thorough, but terse. It also explains differences between versions of Java, which can be very important when you're looking at old code with deprecated methods. If you're a coding guru who wants to add Java, this is the book for you.

Wikis: a skill?

WingedPanther — Fri, 30 Sep 2011 03:30:14 GMT

I've run into something recently, and it's started me wondering: is using a wiki a skill that isn't normally taught?

For reference, I've posted on around 4 different wikis, including MediaWiki (private server), Hatta Wiki, and TiddlyWiki. In each case, after poking around at documentation on formatting markup, I've quickly started using it to organize my thoughts, track various types of information, and generally increase my productivity and organization. I find them to be wonderful tools, with WYSYWIG wikis being the easiest to start using and the hardest to make quick updates on.

With that in mind, I find it odd that several quite intelligent people seem to be having issues with them. If you're not a programmer, I can see the markup as being somewhat off-putting, but I've seen technical guys fumble at trying to be productive with them, as well. It raises a legitimate question: is this a skill that needs to be learned? Is learning it related to being familiar with HTML in general? Is this something that is only useful to certain people, but not others, based on how they process information?

Right now, I have more questions than answers. All I know for sure is that I don't see why more people aren't embracing them.

Book Review: Data Analysis with Open Source Tools

WingedPanther — Thu, 01 Sep 2011 11:36:51 GMT

One of the questions that gets asked a LOT on this forum is, "How much math do you need to know to be a good programmer?" The general consensus is usually something along the lines of, "Some algebra, but more always helps." As a mathematician, I never really like that answer, because I know there is so much more that it is good for programmers to be aware of.

I picked up Data Analysis: with Open Source Tools about 9 months ago, and have been reading it steadily since then (I keep finding "must read now!" books). This is one of those books that does a great job of illustrating why you should know more than just algebra. It covers the math and programming strategies of how to solve various problems in data analysis based on real data, with packages that were developed for those types of problems.

It starts with basic descriptive statistics, including discussions of histograms, linear regressions, data plotting, modeling, etc. Almost immediately, the author, Philipp K. Janert, deviates from any statistics book you will find, and discusses the problems with all the standard regression tools. Simply stated, they frequently don't work well on the types of data we encounter in the real world, and computers can give us better models with far more ease than anything that was available more than 30 years ago (most of stats was invented more than 100 years ago). He also gives numerous examples of using Python's NumPy and SciPy libraries to facilitate with analyzing data. GSL (a C library) is also discussed, along with R.

That covers the first two sections of the book. In the third section, he discusses data mining. In particular, he goes through the various issues with understanding realistic, multivariate data. This isn't like a stats class, where the problems are straight-forward and the results are immediately satisfying. He instead tackles how to explore data with 17 different parameters (wine characteristics) or or detecting clusters of data.

The fourth section discusses a few issues of how data gets used. Most of this work is done for business, so he discusses how business people think, financial concerns of data, and how predictions are made.

Throughout all of this, Philipp makes numerous book recommendations, lists sources for a variety of interesting data sets, and discusses a LOT of math. Basic statistics, Calculus, advanced statistics, and linear algebra are discussed frequently. The assumption is that you are either familiar with the concepts, or will study them on your own. If you know nothing of the concepts, you will quickly discover there is a lot that you might be asked to do that requires (gasp!) more math than you were lead to believe you needed to know.

Oh, the appendices. There are three of them: programming environments/languanges that are available for data analysis, an overview of calculus, and a discussion of how to work with data in general terms (file formats, SQL, where to get your data).

This is a very good book on a complicated field. It makes a point of stating, repeatedly, that real-world data is never as clean as the data in math books. It also makes a fantastic argument for anyone who wants to get a bachelor's degree in computer science also getting at least a minor in math. Will you do this type of analysis all the time? No. On the other hand, being able to analyze data, and being reasonably competent with programming, got me my first coding gig doing database migrations and updating statistical calculations tools.

I still say: learn all the math you can. You never know when it'll come in handy

Book Review: Manage It!

WingedPanther — Thu, 18 Aug 2011 01:33:16 GMT

In case you didn't guess, this "programming" book is actually a project management book, focussing on managing software projects. So, should you bother with this book? I mean, most people reading this want write software, not manage it, right? There's a few things that make it a worthwhile read. I'll break these down into a few categories, depending on where your programming career may be.

1) You work as a programmer for a company. This will give you an idea of what the project manager is, or should be, thinking. If your project manager frustrates you, this may give you some ideas for how you can help him/her help you.

2) You work for yourself. You need to be your own project manager. You may be the boss of a company, or a contractor, but you have to manage yourself. This will give you a LOT of ideas about how to keep track of what you're doing, and how to plan it.

3) You're learning the trade. If you're taking classes, there are a lot of tips and tricks for how to manage your homework projects. This will give you a lot of ideas about how to start working, now. You'll get tips on how you should be developing your projects, and how to manage your time.

I'm in category 1, and it has affected how I manage my own work. I tend to have a lot of small projects I'm working on. I basically have a project portfolio I'm working on at any given time, and have a lot of latitude to balance my workload. This book gave me a lot of ideas for how I can improve how I organize my own work. This was definitely a 10/10 for me.

Book Review: Release It! Design and Deploy Production-Ready Software

WingedPanther — Tue, 26 Jul 2011 11:42:19 GMT

I know, you're shocked that I'm reading another book by The Pragmatic Programmers. This is a book about what types of things you should look at doing when you get ready to release a major software product. That should immediately alert you to what it is NOT about.

This is NOT a book that will help you get through your programming homework. It will not give you insight into how to design your program, or how to work as a team. The examples are consistently dealing with huge e-tailer websites that deal with things like getting 250,000 hits per hour instead of 20,000 hits per hour on the day of site launch, or a service company reducing their capacity on Black Friday at the same time marketing was drumming up traffic for that service.

So, this is a book about doing programming on systems that utilize load-balancers, failover systems for databases, etc. In addition, Michael T. Nygard, the author, talks primarily about Java and Java's features in this type of system. He gives acknowledgement to Ruby on Rails, and speaks frequently about Oracle for databases. You will also see a lot of commentary about Sun Servers, since this was written in 2007, before Oracle bought them out.

With all that said, it has a lot of useful information for anyone who is looking at writing big to huge systems. The book is broken into several major sections: Stability, Capacity, General Design Issues, and Operations. Each section covers some major concepts, and starts with an anecdote from his experience with a large system failing.

In Stability, he sets the example with an airline system that crashed because of a cascading failure. Access to the database got overloaded, and it started causing blocked threads in other systems, which caused user frustration on the web portals while blocking out airline personnel from being able to process boarding. With this illustration in mind, he discusses ways to prevent failures in one subsystem (such as a database), or the connections between two systems (such as a firewall that decides to block calls), from taking down the entire system. He presents these as a series of anti-patterns and patterns, and illustrates how to cope with problems. If you assume things will break, and prepare for it, then your system will be able to limp along instead of collapsing.

In Capacity, he starts by looking at a launch of a new website. They were planning for a maximum of 20,000 concurrent sessions. Half an hour after launch, they reached 250,000 sessions and the site crashed. He then goes on to discuss Capacity anti-patterns and patterns, including proper handling of session length, handling of session data, etc. He also talks about how "users" will violate your expectations. A lot of web-crawlers do NOT act like normal users. Google, Yahoo, and Bing may behave themselves well, but there are always home-grown crawlers that can behave quite poorly, such as spawning hundreds of connections per second, each of which creates a new session object on the server. It's what you didn't plan for that will get you, and you have to plan for it.

General Design Issues talks about miscellaneous things related to networking, security, etc. In general, there are lots of little things you can do to help. One thing he trashes is the notion that "CPU's are cheap" and "RAM is cheap". When you're talking about enterprise class hardware, this simply stops being true. High-end servers range from $200,000 to $1,000,000 for an empty shell. The CPUs are similarly expensive. Anything you can do to lighten that load will make a huge difference in costs to the team using the software. We saw something similar with the release of Windows Vista: it came out as bloatware, and couldn't run on the netbooks that were suddenly popular. The fixed it in Windows 7, but came close to giving Linux a huge commercial success. The Windows XP end of life got pushed back because Microsoft didn't anticipate hardware getting smaller instead of faster.

The final section is Operations. There are two major concerns in this section. First, make your software transparent. If a vendor suddenly throttles back availability of a service at the exact time you slam it, you'll never figure it out if all you know is the customers are complaining. You need the ability to see what parts of your software are getting stuck. Also, you need to work WITH the IT group. I've got a buddy who does IT as part of his job, and he hates it. Nothing causes him more grief than change. Any change causes problems. Opening a port causes problems. Tracing wires to figure out which jack is dead because things aren't documented causes problems. New software versions? Yeah, they cause problems too. You want your software to be as IT friendly as possible. That includes logging to any location they want, gradual upgrades without outages, etc.

This book will NOT help you create a change counting program. What it will do is help you start making decisions on real software that are realistic. Can your software run without administrative privileges? Can your software handle an unresponsive database gracefully? Does your QA process test the same 0, 1, many relationships that production will have? Do errors get logged someplace? Do status messages get logged in that same place? Can grep parse the logs easily? Can you tune your software on the fly, so it can be made to limp along if something goes wrong?

Some things will not apply to the software you are getting ready to build. I see many things that apply to software I work on, and it even helped me figure out a weird bug in one of the packages I support.

Learning a new language: C#

WingedPanther — Sun, 19 Jun 2011 00:41:01 GMT

Last Tuesday, I decided it was time for me to finally learn C#. I feel pretty comfortable with C, C++, Delphi, Lazarus, VBScript, JavaScript, and ColdFusion. I'm also familiar enough with Java, Lisp, and a smattering of other languages to feel pretty confident that I can do this.

As a result, I picked up C# 4.0 Pocket Reference and started reading. I got about half-way through it when my first day off hit this morning. Having already installed Visual Studio Express, I started coding. Twelve hours later, I have a basic project management utility that can save/open files in XML format, stores tasks and subtasks in a TreeView, with the ability to create/delete nodes, promote them, demote them, and generally rearrange them as desired.

It's not fancy, but it works, and is pretty error proofed (except loading badly formatted files).

Things I discovered during the process:

The Visual Studio editor is fantastic. The code-insite facilities make it very easy to find the desired methods, avoid typos, and understand what the methods/properties do. In addition, you get compiler errors appearing/disappearing as you type, which makes it very easy to detect and correct mistakes in your code as you make them.
Once you are fairly strong in a few languages, it is really rewording to dive into a new language and find success. I was able to write a non-trivial program, complete with buttons, menus, and various GUI elements as my first C# program. I probably learned far more than I would have if I had just started knocking out the usual "Hello World" apps, and escalating up. In addition, it was quite rewording to have something that's actually useful (though it could use a few dozen more features).
XML is a really handy file format. You can easily test whether your save method is valid by opening the file in IE (my initial save failed). Parsing XML while reading is equally easy.
I've been plowing through Java: The Complete Reference, and while it's a fantastic book, I've been making the mistake of not actually coding anything. By contrast, the C# Pocket Reference let me get a quick summary of the language and rely on the Web and IDE to cover the gaps.
If you're pretty strong in one or more languages, writing non-trivial programs in it, you can start using new languages that use the same programming paradigms pretty quickly. It's a nice feeling.

On a side note, I think C# does a nice job of picking the best items from Java, without some of the dumb mistakes. Sort of 95% Java, 5% C++.

Book Review: Ship It! A Practical Guid to Successful Software Projects

WingedPanther — Wed, 20 Apr 2011 12:40:55 GMT

Before I get too far, I'll say this: if you have already read a few books from the Pragmatic Bookshelf, you will not find a lot of new ideas in here. However, the book is short enough that it's a very easy read, and won't stress you out.

The focus on this book is simple, what can you do to get your product out the door? The material is broken down into four sections:
1) Tools you'll want in your company. This ranges from one-click builds to issue tracking to Continuous Integration with automated testing. These are the basic infrastructure type things that will determine what you CAN do.

2) Project Techniques. These are the methodologies you use. These range from having one person act as a buffer between the programmers (who need a lack of interuptions) and managers/customers (who need regular feedback), to having code reviews. The biggest item, however, is The List. This one item is first, and referred to constantly throughout the rest of the book. The idea is simple: have a prioritized list with time estimates. ALL priority 1 items must be in process before anyone can snag a priority 2 item. The list is flexible, and customers/managers/etc can add items to the list, but it's a great tool to let people see the impact of changes. It's also encouraged that you do this on both a personal and team level, and keep the list easy to see. I started using a personal wiki (http://hatta-wiki.org/) as my list, and have already pointed it out to my manager at my job.

3) Tracer Bullet Development is explained. This is a development methodology where you stub out all your method signatures first, but they don't do anything. For example, your code for ValidatePassword might look like this:
Code:
bool ValidatePassword(string username, password)
{
  return true;
}
The goal is to be able to COMPILE your project as soon as possible. You then build the actual code for the hardest parts first, and move on to the easy parts. Doing the hard parts first lets you adjust timelines early, and have only easy stuff as you approach the finish line.

4) Common Problems. Once all the preceding is in place, a list of common problems that software shops face is examined. This ranges from the rogue developer who likes to "refactor" code, breaking functionality in the process, to how to test "untestable" code. For about half of these items, having The List is a major component of addressing the issues. Solutions are explained from the perspective of a programmer, manager, or team leader, as appropriate.

There is one more section that makes this book stand out above the many others out there: the appendixes. Each appendix has URLs for various software packages that where available at the time of writing (2007). It will give you a great place to start on finding both free and commercial revision control systems, automated build systems, etc. Saying "get a revision control system" is easy. Saying "Here's five that work well" is something very different. The software landscape has changed, but it's still a great starting point.

It's a fun read, and it's practical... dare I say "pragmatic"? The best part is: I got good ideas from it.

Book Review: SQL Antipatterns

WingedPanther — Sat, 16 Apr 2011 14:31:35 GMT

One of the things I'm responsible for at my job is adding new features to one of our products, which often means adding new database tables/fields. That, along with various debugging activities, mean I am regularly having to work on database design and queries.

The title of "SQL Antipatterns" just screamed "buy me!", so I finally did. This book lists 24 common errors developers make when working with databases. They are grouped into four major categories: logical database design antipatterns, physical database design antipatterns, query antipatterns, and application development antipatterns. There's also a short review of normalization, with comments on how several of the antipatterns are simply violations of normalization.

From a technical standpoint, this is a book that deals with real issues. I have seen many of these antipatterns in actual databases, either during migrations from old database or in products I've worked on. Sometimes they've been valid exceptions, but often them been clear violations of good practices.

Some of the items that really stood out for me: it's apparently common to use a comma separated list instead of using a child table for storing the items. This one absolutely blew my mind! Another was using a check constraint instead of a foreign key constraint to limit the values that can be entered into a column. Again, people really do this? It makes adding new legal values quite hard.

Every antipattern is described in six stages: first is an example story that illustrates a likely consequence of using the antipattern. Second is a description of what the developer was trying to achieve by using the antipattern. The goals are almost always legitimate. Third, the antipattern, the obvious but incorrect solution, is described. Fourth, you are given tips to spot when people are thinking about the limitations the antipattern will impose. Fifth, sometimes there is a valid reason to use the antipattern, those instances are described. Finally, the generally correct solution to the objective is described.

The result is everything is kept in a real-world context (many of the examples revolve around a bug-tracking system), with real-world motivations. There are many anecdotes about the actual costs of using the antipatterns, from wasted developer time to inefficient queries, to nearly impossible to craft queries.

Finally, after reading the antipatterns, the summary of normalization made perfect sense. The first few forms are described in terms of the antipatterns they cure, and the motivation for normalizing your database will make a lot of sense.

The book is fun, very readable, and very informative.

Book Review: Effective C++ Third Edition

WingedPanther — Mon, 11 Apr 2011 00:59:01 GMT

After hearing numerous positive review about this book, I decided it was time for me to finally pick it up. Having a little birthday cash was a great excuse to snag it. After reading it, I intend to get both More Effective C++ and Effective STL.

For me, this book really opened my eyes to how much I don't know about C++. For those of you who haven't read it, did you know that Template Meta-Programming is a form of Functional Programming that is Turing-complete? Did you know that Template Meta-Programming is programming that runs in your compiler, trading compile time for run-time efficiency? Things like this make me feel giddy inside.

This was really a book about how C++ can trip you up, and how not to get taken in. It includes warnings for Java and C# programmers, where appropriate, to help avoid common misconceptions from similar-looking constructs. The early chapters contain advice that you can easily find on this site, or many others. They're easy to grasp, but the reasoning is also explained clearly, along with examples of what happens if you don't follow the advice. The later chapters can seriously push your limits, if you aren't an expert C++ programmer (and I don't think of myself as one).

I strongly recommend this book if you are a competent C++ programmer. If you are familiar with design patterns and the STL, you should be in good shape. If you don't know the basics of templates and inheritance, you probably won't understand half of what's in the book. You may want to look at this edition if you have the second edition, as well, as it has a lot of material about C++0x TR1 in it, and has been restructured with new material.

Now, with my above statement, you may be afraid it's intimidating, dense material. It's not. The writing style is very accessible, with clear, concise examples that illustrate the point. You will learn more about the rules of C++, and how subtle rules can influence things. I learned, today, that operator new actually has an infinite loop if memory cannot be allocated, something that I never knew before.

This is an excellent book to have in your C++ library, if you intend to make this one of your primary languages. If nothing else, it will help open your eyes to the complexity of the language, and the incredible power in offers.

Playing with Wikis

WingedPanther — Sun, 10 Apr 2011 04:01:29 GMT

I recently started looking at using a wiki for internal communication and general note taking at my company. We have support management software, documentation management software, revision control software, etc. No wikis, however, were in place. After doing some searching, I found a ridiculous number of wikis. After a certain amount of looking around, I finally decided to try http://hatta-wiki.org/ on my home computer.

The next day, I installed it on my Mac at work. By that afternoon, I was using it to track my progress on some work for a customer, and to provide summaries of the communications (sometimes hundreds of messages in the support management software) while one of my coworkers logged instructions for one of his repetitive, but mildly obnoxious to repeat, tasks. Meanwhile, at home I'm logging the ideas I have for fanfiction stories, software to investigate, etc, etc, etc.

Tonight, I set up a copy on my wife's computer so she can track her fanfiction stories, including chapter summaries, ideas, etc. Heck, if she wants to use hers to log pina colada recipes, I suppose she can.

Here's my thoughts on it: I find that my memory regularly fails me. Having a way to log ideas, organize thoughts, and generally keep track of information, is very helpful. For me, having a simple tool that I can start using without requiring a lot of configuration work (Mac has a dmg file, Windows has an exe, and Linux has very modest package requirements) is really nice for experimenting. For a larger company, having a full web-based solution with database and full backups, etc, would probably be important. This is doubly true if you need to enforce logins, etc.

I suggest people give it a shot. The learning curve is pretty short, but having the notes is really convenient.

Book Review: Practices of an Agile Developer

WingedPanther — Fri, 25 Mar 2011 11:25:27 GMT

Sunday night I picked up "Practices of an Agile Developer", and started devouring it. Last night (Thursday) I finished it. It was a delightful read.

The basic premise of the book is: You may want to do agile development, but you have some habits that are getting in the way. The book is broken into several seven chapters, each with about six tips (45 in all). Each tip starts with the typical thinking that causes you to not follow the Agile practice, followed by why you need to follow it, what it feels like, and how to keep it in balance.

Tips include how to function on a team "3. Criticize Ideas, Not People", how to satisfy customers "10. Let Your Customers Decide", how to write your code "28. Code In Increments", how to debug "34. Warnings are Really Errors", and comes back to teamwork "41. Be A Mentor".

There are also lots of references, both in book format and on the web. The goal of the book, throughout, is simple: Agile Development practices are not about having a special method, they're about doing things in a way that makes your work easier to manage in the long term, not just the next week. Banging out crappy code quickly, fighting with your teammates, and checking in buggy code (or never checking code in) are ways to avoid helping out your team (even if it's a team of one).

For me, this was a very inspiring book on how to do things with quality in mind. Five stars.

Open Sources Licenses - Destroying Freedom

WingedPanther — Sat, 12 Mar 2011 20:14:51 GMT

Okay, before you freak out, I actually like open source software, and appreciate open source licenses.

With that said, I think that some people use the wrong license for the product they are releasing. There are a few basic styles of license that I want to look at, and I'll suggest what I think each should be used for.

1) GPL: this is license where if you incorporate it into your software by any means, it instantly makes your entire program (through linking) also covered by the GPL. If you hand out your program, you must make the license and source code available as well.

2) AGPL: This is the Affero GPL, which means if somebody USES your software (such as a web site), you have to include a button to let the user download your source code.

3) LGPL: This is the "Lesser" GPL or Library GPL that allows you to link to the package, and you only need to release the library's source code, not your own. Changes you make to the library, however, must be made available with your software.

4) MIT License: This is the one where you can do what you want, change it how you want, etc, and you are under no obligation to maintain your copy under any particular license.

So, what's got me so up in arms about these licenses? Something rather simple. I work for a private company that, among other things, produces web portal software to allow our customers' customers to view data that is produced by our desktop application, and supports some basic interactions with it.

As part of staying on top of options, I've been looking at migrating the web-app to PHP or ASP.NET. This is a pretty simple thing, but I need to ensure that I can do things like generate binary Excel files for reports, and watermark PDF files with timestamps. In addition, I have to enforce concurrent licensing of the product, and make sure that our (primarily) non-technical users can get the whole thing running with minimal fuss.

Let's start with the license enforcement. This means I must be able to encrypt the file that processes logins to ensure that the maximum number of simultaneous users is not exceeded. Releasing the source for this file is simply not an option, because of company policy.

For simplest setup for a non-technical user, PHP and ASP.NET both seem reasonable, though ASP.NET is a bit easier. Here's where things get ugly. The defacto tool for generating Excel files in ASP.NET is released under the AGPL, or under a commercial license that wasn't even designed with the concept of reselling in mind. We sell our product. It is simply not compatible with either option.

With ASP.NET, I kept running into this type of issue, either the licensing costs of a component for a minor product cost hundreds or thousands of dollars, or they are covered by the AGPL.

By contrast, the corresponding libraries for PHP were covered by either the LGPL, or MIT-style licenses. php.ini will be more difficult to explain to our customers, but I can work within my company's constraints.

What kills me, in all this, is reading articles about how the GPL and AGPL help to preserve software freedom (as in speech, not in as beer). Guess what, it actually inhibits my freedom. You see, I don't always have the freedom to open-source my software, no matter what I may want to do.

The LGPL and MIT licenses allow me to use, and contribute back to, open-source projects while working on projects that I am required to keep closed-source. By contrast, GPL and AGPL licenses would simply turn my product into something I am not allowed to release by my company, or even (in the case of AGPL) demo.

For me, if you create a software LIBRARY, then the most appropriate way to license it is as LGPL or something even less restrictive. This makes sense to me, and would enable more people to benefit from solid, useful libraries. A complete application, on the other hand, is where GPL or AGPL make sense. Want to share your web-app, AGPL makes sense! Want to share an application you made, GPL away!

What's bad is that even the Free Software Foundation admits they had to create the GCC libraries as LGPL to get them used, yet they want others to release libraries as GPL.

I love open-source software; I use it regularly. It is frequently better quality than the equivalent closed-source application. Unfortunately, it seems like some people want to set themselves at odds with those who make a living creating closed-source software. There is a middle ground, and I think the LGPL is where you find it. Both parties are protected, yet the FSF wants us to avoid it.

Book Review: UML: A Beginner's Guide

WingedPanther — Mon, 07 Mar 2011 13:51:39 GMT

I bought this book as an impulse buy a couple weeks ago. As you may have noticed, I like to pick up programming books. This one will not be on my top recommendations list.

To be fair, http://www.amazon.com/UML-Beginners-...9504647&sr=8-1 is a fairly easy book to read, and it does introduce the basics of UML in a pretty simple way. What bothers me is the vague sense that I'm being talked down to. This is not a book that is targeting a programmer who wants to add a new tool to the toolbelt, it's a book that is meant for someone who is still learning Java or C++ or some other OOP language.

The next issue is the copyright date: 2003. It discusses the UML 1.4 and the "upcoming" 2.0 spec. The reality is that the current spec is 2.3 and can be found here: http://www.omg.org/spec/UML/ The result is that we have a fairly out of date book sitting on bookshelves. As you know, if you've read other books I've reviewed, old doesn't always mean out of date. In this case, I'm disturbed that this book hasn't been updated in the past 8 years.

My other issue with this book is that it takes an almost mindless "UML is great! All hail UML!" attitude. It doesn't really talk about when UML is or is not appropriate, what its limitations are, etc. I challenge anybody to make meaningful use of class diagrams on a Lisp or Haskell project.

What the book does well is give the user a solid sense of the basic ideas behind each of the major UML diagrams that can be encountered. It fails to mention any non-commercial tools for making the diagrams, such as Dia, Dynamic Draw, or Umbrello, but that's another sign of the book's age. You will feel fairly comfortable with what UML diagrams represent, and how to produce them when you get done.

The book also clearly states that it will NOT cover all aspects of UML. The goal is to get you up and running with UML, not to completely cover all details of the language. That is the purpose of the spec.

You will also get a very brief introduction to OCL (http://www.omg.org/spec/OCL/), which probably deserves its own book.

Overall, I'd rate this about 3 out of 5 stars, which is pretty disappointing, given the quality I normally encounter. I would recommend simply finding online tutorials rather than spend $30 on this book. If it were under $20, I'd probably give it 4 stars, but you will be paying too much for what you really get.

Also, be sure to check out some of the critiques of UML in general. If you read this book with your brain in neutral, you might not notice that using UML to communicate with non-programmers will require teaching them what you are doing. It's meant to be simple, but isn't simple once you move past Activity diagrams, and even those can be confusing.

Book Review: Seven Languages in Seven Weeks

WingedPanther — Sat, 22 Jan 2011 15:14:13 GMT

I just finished reading one of the most unusual programming books I've ever read. It's an introduction to seven languages in about 300 pages.

A couple warnings from the author, and a convinced reader: this is a book for self-starters who are willing to do some leg-work on their own. If you just read the book cover-to-cover (like I did), you will not learn any of the languages, just get a vague sense of what they can do.

The motivation to read this book is simple. If you find yourself doing what I do, you may know several different languages (C, C++, Java, C#, PHP, a few others) and they all start to feel basically the same. The goal of this book is to start in your comfort zone, and steadily move into unfamiliar territory. Every language includes an interview with a significant person involved in the language's origins, and a brief history of the language.

The format of each chapter is an intro, three days of "instruction", and a summary. You won't see much in the way of "hello world" programs. You will dive face first into what makes each language unique.

Language 1: Ruby. This is basically just an interpreted OOP language. On interesting note: there are no primitives, EVERYTHING is an object, even 4. For me, the most interesting aspect of Ruby is this: you can change the definition of a class during program execution. This is both very powerful, and gives you the ability to completely break the scripting environment.

Language 2: Io. This is an interesting shift into prototyping languages. The idea here is pretty simple: there are objects, but no classes. Objects can have methods and properties added to them, and they can be copied to create new Objects. This is also the paradigm used in JavaScript. Io is similar to Ruby, in that you can completely rework, or break, the environment. Io lets you redefine every aspect of the language, as needed.

Language 3: Prolog. This is the first language that will take you into the Twilight Zone. It is NOT a programming language in any conventional sense. It is a Logical-Declarative language. You don't write the steps for execution, you write the constraints for what is and is not allowed, and Prolog finds what satisfies those constraints. I've got a book on how to solve sudoku puzzles in VB, that takes around 100 pages to create a solver. Prolog solves a 4x4 sudoku with 26 lines of code, and it only takes about 8 pages to explain the logic.

Language 4: Scala. Scala is the first language in this book that runs on the JVM. It's a hybrid language. It supports OOP programming and Functional programming styles, and can leverage the Java library for good measure. Scala also introduces a new way to approach concurrent programming, a topic that is discussed in the rest of the languages. Scala begins the process of avoiding side-effects in threads to avoid concurrency problems, which makes multi-threaded programming easier.

Language 5: Erlang. This is a functional language that was evolved from Prolog. This is a language that is designed specifically to be robust in a concurrent environment: maintaining telephone switching for Ericsson. It does this by spawning processes, not threads, and providing mechanisms for processes to monitor each other and communicate. Combine this with the ability to update code on the fly, and you have a language that has created programs with an uptime measured in YEARS.

Language 6: Clojure. Clojure is a functional language. Clojure is a dialect of Lisp (specifically, it's a Lisp-1 dialect, unlike Common Lisp, which is Lisp-2). Clojure runs on the JVM. The basic idea of Clojure is that everything is a list (though Clojure represents Sets, Vectors and Maps with slightly different syntax), and that a list is ALSO a function. Data is code, code is data. It means you can build functions on the fly and then execute them.

Language 7: Haskell. This is the only pure functional language in the book. It takes avoiding side effects to an extreme, making some things that are easy in other languages hard, but also making some hard things easy. You can have infinite lists in Haskell (though you can only display some items on the list at a time, of course). You can do input and output, but it's hard. You can also express recursion easily and simply. It has similar list processing abilities to Clojure, making it extremely powerful.

Overall, if you haven't studied any non-imperative languages before, this book will really stretch your thinking. It is not meant for casual reading. For myself, I found Erlang to be particularly enticing. It takes two lines of code to define a factorial function, and it can calculate 2000! with perfect precision. I like the idea of being able to write code in Java, Scala, and Clojure, and mix them together to create powerful abstractions in whichever language is best suited for the task.

The book ends each chapter with a discussion of strengths and weaknesses in the language, and ands the book with a comparison and contrast between them. You can read the chapters in any order, but it is assumed you read them in order, and concepts introduced in earlier chapters will get light treatment in later chapters.

You will not learn any languages from this book, you will learn new ideas, and you will learn how to teach yourself languages by engaging them face first, instead of the usual slow approach of most books.