All Things Software

Is the Portal dead?

Fri, 23 May 2008 07:41:55 -0500

You are probably asking yourself, which Portal? There are so many things out there today with portal-like features, that's it hard to tell one from the other. The Portal that I am referring to, is the Penn State Portal @ https://portal.psu.edu/. As many of you know a long time ago, I was the primary developer for the Portal. I'm not going into all of the historical stuff, I already did that in a previous post.

When we looked at the portal concept, a number of us felt it was great idea. One place to go to for all of your stuff, whether its Penn State-related or external like CNN.com. And for a period of time, we had some traction. The portal was the place to go for a number of things like RSS feeds and chat. When we were doing our design, we make a conscious decision that we were going to settle on using RSS for content-type channels. At the time the specification was in the hands of Netscape and the version was around 0.91. Software to take RSS and convert it to HTML existed, but its performance was not very good. So we ended up writing our own parsers using compiler tools (Lex and Yacc). Then for chat, we had a Java Applet (yes an Applet) that supported Jabber in the portal. Another thing that we can up with in the portal was the concept of your personal bookmarks. That way a person could log in and always have access to their bookmarks. Again another great idea at the time, now with sites like del.icio.us, you may not need a capability like that.

So where have things gone? Well today, everybody and their brother has their own RSS aggregrator (News Reader). I personally use NetNewsWire. And for things like chat, we just launched a Jabber Alpha/Beta that supports native clients. A web-based version is on the way. So there are a number of things out there that replace the functionality of the Portal. I will be the first to admit that. I have not checked usage numbers in years. But, people still use the portal. Why you may ask? Well it gives them something that many other sites do not, personalization and customization. Your portal is personalized for you, because we know a little bit about you based on your directory information. This is a pretty neat concept that still has merit. Customization of course will allow you to go in and pick and choose the concept you want to see.

Back to my original question, is the Portal dead? I think it is on life support, but not dead. People at Penn State and other Universities still find value in the portal concept. Remember a single place to go for all of my stuff. If I had my way, what would I do to resurrect the portal?

Complete rewrite to make it Web 2.0/3.0.
Make content publishing more user friendly.
Try to make it the hub for all Penn State applications. Those applications do not have to be wholly contained in the portal, just use the portal as a launching point for them.
Make things easier to use (look at Google's Portal for example). And you maybe asking why not just use Google? That question has been asked in different forms before, because Penn State content should stay inside of Penn State.

Since others and myself have spent so much time on the portal, I sure hope we can save it and breathe new life into it.

Types of Code, WebMail, and another story too.

Fri, 18 Apr 2008 07:18:08 -0500

Types of Code Story (Waterfall):

Back in the day, when I was at Raytheon I was involved with writing a number of proposals for a variety of things. Sometimes the work was interesting other times it was real boring. One part that was interesting were the line of code estimates. For a paragraph of text that describe a particular function, you would have to come up with a line of code estimate for it along with the percentage breakdown based on type. Then the financial folks would take that number and determine a cost. Sometimes the estimate would give us a win, others times not so much as my friend Mark Miller would say.

The types of code that we would use had three categories: hard, medium and easy. The productivity of each one was 10 LOC/day, 13 LOC/day and 15 LOC/day respectively. So you are probably wondering what the heck? A person is only going to develop 10 lines of code in a single day if the code was deemed hard. Well, in a word yes. Those numbers included more than just writing 10 lines of code. It included all of the up-front design, reviews, coding and testing. So in the end you were getting fully tested code. Back then we were a waterfall shop and now from what I hear things have more on into other methodologies. Here are some examples of each of the types of code:

Hard - device driver development. Yes, back then we did that since we built and engineered our own hardware.
Medium - interface development. Writing X11 programs at the time was not very easy.
Easy - simple utilities.

WebMail (Agile):
Now in present day, we are doing some great strides with Agile techniques for WebMail. Our development cycles are typically 2-3 weeks. Within that time, the planned features are discussed, code is developed and full regression testing is performed. I am very pleased with the product that our team has put together. On May 12th, we will be doing another launch of WebMail. This one which has been in beta since Spring Break, will enable us to turn off WebMail2. The new version of WebMail will have all of the existing functionality of WebMail2 and loads more.

My final story (SCRUM):
And finally my story, one of the tenants of the Agile project management process known as SCRUM has to do a lot with how the team functions and communicates. We (Applied Information Technologies, Emerging Technologies and others) participated in a SCRUM effort a while ago and probably none of us knew it. The task was to take Shibboleth, and use that as the basis of authenticating with Napster. Shibboleth enabled our Penn State students to authenticate at Web site and have only that they were a student passed onto Napster. Napster never knew who the student was, just that they were a student. There are many parts of shib and I really do not want to go into them this morning. Back to the SCRUM portion of the post, we (AIT) never worked with Shibboleth, heck for the longest time, I could not even spell it. ET had a pilot already going, but now we had to ramp up for large scale production and we had less than 30 days to do it. There were so many unknowns with performance, like how many machines do you need? At the time, Kevin Morooney was the Sr. Director for ASET, he of course realized how important the project was, like all of us did. However he did something novel which is part of SCRUM. We would meet for 10-20 minutes every morning go over the day's objectives and previous day's results. Then at the end of the day we would meet again to see how we did and plan the next day's objectives. Let me tell you, this method worked out great. How often do you find yourself in a situation where you have a major effort going on and you are only meeting weekly, bi-monthly or even worse monthly? If the effort is critical, you need to take a page out of SCRUM's play book and do the daily meetings. It worked out great for us. After all of the planning and testing we did, when it came time for that first student to log in, we were watching the machines and things worked.

So there you have it, the past, present and the future all wrapped up in three little stories.

RISK

Tue, 15 Apr 2008 12:26:46 -0500

What a title? RISK (even in uppercase), pretty scary isn't it? I did a quick google for some definitions and I really like this one:

Risk: The uncertainty of an event occurring that could have an impact on the achievement of objectives. Risk is measured in terms of consequences and likelihood.

By the way, I am not talking about the game of Risk, which was the first hit from google. No, folks I talking about risk with regards to a project. All items of risk should be taken into account during all phases of a project. In addition, the affects of risk should be accounted for in the overall schedule. Here are a couple of examples of risk that can affect a project:

Dealing with an vendor that delivers hardware that is either missing or not functioning.
What do you do if you technical lead or other key player decides to resign or worse becomes ill (the hit by a bus scenario).

And you can look on-line to find many more examples of risk. When I was working at Raytheon all of the proposals that we wrote had a special section in them to list the risks associated with the project. For each risk we also had to list how we would mitigate the risk. This of course affected our bottom line, and being a profit driven organization it was all about making money.

So what do you do about risk? Well first off, you need to acknowledge that it exists. You would be a fool not to. Look at the all of the external forces that can affect your project. Each force represents a risk, whether its a hardware vendor or the company doing your copies. You need to acknowledge the risk and come up for a plan to mitigate said risk. The same thing applies for internal forces too. Risk exist there too, things like staffing and commitment all affect the overall project plan. Risks, like everything associated with a project needs to be constantly evaluated, because at different stages of the project the level of risk could change. Early on in the project, the technical lead leaving would have less risk than later during the overall development.

I used to be accused of padding estimates when I gave them. Why? Well I knew some of the risks, and wanted to take them into account. Reality is these days, I still do that. Because worrying about risk and its affects, brings me to my final point. Be Realistic! Do not kid yourself that things will go perfectly, they never do. However by acknowledging risk and its associated affects can make things easier when things just do not go right...

Is this your project team?

Mon, 07 Apr 2008 07:42:51 -0500

Yesterday, I was reading some blogs on reddit.com, and I came across this photo in the "funny" section. So I was wondering if anyone else out there feels there project team looks like this? Back in the day, when I was writing the Penn State Portal. Yes, I wrote the portal from bottom up in "C" and Perl. It took about six months to do, but in the end I was pretty happy with it. Now, back to the picture, the kid in the pot is definitely how I felt. At the time, the portal team was full of managers and one programmer (me). If you ever do a DNS lookup of portal.psu.edu, you will find another analogy that I associated with the project. The portal machine is named PennDOT aka, many people in white hat watching one guy digging a hole.

So what should the real team look like? Well I have blogged about that before, check the archives. In essence, it needs to be a real team with shared roles and responsibilities. The team shares the credit for a success and the blame for a failure. The team works on hitting deadlines and managing expectations. No single person should be doing the bulk of the work. The other parts of the team, the leader, the manager and PM, need to support the team members. But, they also need to ensure that things are in place so that deadlines can be met. Those deadlines are deadlines for the team, not the poor sap stuck in the pot of boiling water. Let's hope your team photo has a much larger pot with room for everyone.

The Tower of Babel

Fri, 04 Apr 2008 08:25:26 -0500

Communications can probably be best described as a tower of babel. People are there and they hear you speaking, but what the understand and hear is completely different from the person sitting next to them. Today's posting is going to be about communications as you have already guessed, not about some fancy software technology. Communication in general is an integral part of any process including a software one. So it is very relevant to the theme of my blog.

So how do we effectively communicate a new process to a group? Let's look at a way not to do it first and then some suggestions how to effectively communicate. As many of you know, one of my duties is being responsible for the architecture, programming and care of Penn State's LDAP servers. I have been doing this for a number of years now. Because of that, I am involved with a number of committees and I have to attend meetings about LDAP. So its been probably three years now, I was called into a project meeting to discuss LDAP. The meeting was supposed to be about how LDAP could be utilized for role-based authorization (another area of keen interest to me). So of course I had many answers and comments. People were asking questions and I gave them answers in painful detail to include how the protocol worked. There were times I was having sidebar chats with my boss about how we need to do things in the future. All of these things and many others did not nothing to facilitate effective communication. In most cases, I probably alienated the audience. Why? Because my communications with them were flawed in many ways. Trust me, it took a great course called ITLP to help me understand that.

Now for the suggestions on how to do better effective communications:

Its all about the message. You need to frame your message so that the audience can understand it all levels and that they have the proper take-aways. This is a easy one if you have an idea of who your audience is, but what about if you do not. Well you start out simple and see where the discussion leads. Remember you are there to help them solve a problem, always keep that in the back of your mind.
Keep the presentations so that only one person presents. I know that tag-teaming presentations is a great concept, but in most avenues its confusing to the user. You need a consistent presentation that flows from topic to topic. Taking time for a new speaker to set up, causes the audiences attention to wander. Do not believe me, just watch them.
Make sure you have a focused agenda for your presentation, and stick to said agenda. The worse thing you can do is just wing it. If you know something that your solution that is problematic or will not work, do not take vital time away from your presentation to sit there and debate solutions with your team. Take the discussion off-line.
After you make a presentation to a group, try to follow it up with an email that re-enforces your important points that you just presented.
Take aways - In the world we will in, being Green is in. I know that killing trees is a bad idea. However in situations like this, giving the audience something they can take back to their office will not only re-enforce the presentation, but hopefully serve as a constant reminder of what happened.
When you are giving presentations and communicating with users keep the presentation portions short. You do not want to dump extra detail on them that they really do not need. Of course be ready to answer their questions if they have them. But, make sure you keep those answers short. Communicate to them a solution to their problem, but be light on the details.

There are many other great resources on-line about how to do effective communications. I have a number of them bookmarked on my del.icio.us (keyword leadership).

Watch out for the striker

Tue, 01 Apr 2008 10:30:53 -0500

For the longest time now, we have been doing code reviews the old fashioned way. We would print out the code and two people would sit and review the code line-by-line. Our notes were either attached to the code or written out and given to the developer beforehand. This is was pretty much what we did when I was back at Raytheon, except we had more people involved.

This morning, I came across a really good tool to help facilitate code reviews. It is called Codestriker. It is written in Perl and uses MySQL as a back end. I put a version up on one of my Linux boxes and created a database on the MySQL cluster we have. The tool is really feature-rich, in that it can work with CVS, SVN and other source code repositories. I have at least three projects in the queue to review, and most of them are new. So this morning, I uploaded the code to the tool. Then I was able to review the code line-by-line. To add a comment, all I needed to do was click on the line number. Then when I review the code again, all of the lines that are in "red" have comments associated with them. The benefits of this tool are:

You now have a history of all of the code reviews for a particular project.
It enables multiple reviewers to review code at the same time.
Developers can log in and address the codes prior to the actual review.
Did I mention its open source?

So if you are in the market for a good code review tool, give the striker a try. I did bookmark on del.icio.us a number of other tools that are commercial products.

Want to chat?

Thu, 27 Mar 2008 08:05:38 -0500

No, not with me, how about each other? Everyone has an AIM account, maybe even a Yahoo one too. The problem with all of these accounts is your are known by names like starblade2000 (my brother-in-law) or jimmyvPSU (me). Wouldn't it be nice to use your Penn State Access Account in a secure manner to chat with other Penn Staters? Well folks, guess what? We have resurrected our old Jabber server. Back in the day the Jabber chat only worked by logging into the portal (https://portal.psu.edu/ ). Now we have a new service (that's in alpha/beta), that is load-balanced, secure and uses Kerberos. All you need to do is point your favorite Jabber client to chat.psu.edu. Your jabber id will be your access-id at chat.psu.edu (jvuccolo@chat.psu.edu is mine). By default we are set up for TLS and SSL, so all of the chats will be secure. Client-wise there are so many out there to choose from (iChat, Adium, Spark, Fire, Pidgen to name a few). In addition, because its jabber, you can inter-operate with people who have google talk ids, jabber.org ids and so on. We also have a conference server up at conferences.chat.psu.edu. Again, try it out and see what you think...

Strategic Database Planning

Thu, 27 Mar 2008 07:44:22 -0500

For the longest time now, my group has been doing a lot with databases. We provide databases for classes and research. In addition, we use it for our people registry (a.k.a. CACTUS). What the heck Movable Type uses a back-end database. So we have instances of DB2, Oracle and loads of little MySQL instances installed on separate boxes. From a maintenance and application development standpoint, this has become a real nightmare. My lone administrator has to ensure that things are patched in a timely fashion not only across the databases but also the platforms.

Last year, before we made the decision that things would go forward with MT 4, we needed to solve a fundamental database problem. The web servers were going to be load balanced, but in the past the instances were not. So I did some digging around and found two solutions for MySQL. They were clustering and replication. Clustering looked very attractive in that it did hot fail-over to other nodes. However as I dug deeper into the documentation , I came across a lot of deficiencies too. The software just didn't look like it was ready for prime time. However replication looked like a really good solution. We were already using a concept like it with our LDAP servers. In that you have master nodes and replicas. If a master fails, you can switch a replica node over to be the new master. So for MySQL what we have is a master with two replicas. In the works is probably another master for master-to-master replication. The nice thing about this little cluster is we can place all of our tiny little databases on one MySQL cluster. As you can probably guess its really great from a maintenance standpoint. Performance is really good too. Right now, we have both MT versions using the cluster along with our Jabber server. So from a strategic standpoint all our MySQL-like databases will use the cluster.

Now on to the bigger databases. We have been using Oracle for our people database since 1999. Oracle has loads of great features that do come at a pretty high cost. For other applications, we have been using DB2. We are mainly an IBM shop and DB2 has some attractive features (like built-in Kerberos authentication). And after version 7.x, it added a stored procedure language. However that language did not rival Oracle's PL/SQL, and the name was confusing it is called SQL/PL. Right now we have a our classes databases, Friends of Penn State and some other databases on DB2. Our strategic plan is to move all of those databases to Oracle. A wise man said a long time ago that "Oracle gets you by the tools". In reality that person was correct, their tools far exceed anything that I have seen on DB2 (have you seen APEX?). Just like with MySQL, the benefits of a single large database like Oracle are really going to outweigh the pain its going to take to migrate some of these databases from DB2.

So where are we at with all of this? Well from the MySQL side, I would say we are making excellent progress. We have moved a number of our "baby" databases over to the cluster. From the large scale side, we are waiting until we migrate to Oracle 10/11 and then we will start the migration of the DB2 databases over to Oracle.

The Good 'Ole Days

Tue, 19 Feb 2008 07:26:54 -0500

People use that expression a lot when they talk about a time when things were just perfect for them. There are times when in my IT career, I miss the good old days. A time very long ago, when my title was Senior Engineer. Engineer, of what you may ask. Well Software, of course. I was at Raytheon and I was engineering new software following tried and true practices and procedures. Ah, the good old days, such a great time. I was a Lead Software Engineer (LSWE as we called them), on a number of projects. That was a good thing too, I had resources available to me, but I did not have to worry about their performance reviews or personal issues. Unlike what I do here as an IT Manager. Even though my real title says, Manager, Research Programmer. You really cannot escape that Manager part, trust me I have tried.

Wait a minute, people are probably thinking being a manager is better, you have people and you can use them to get things done. Well, folks hate to burst your bubble but it doesn't work that way. As a manager, you have to deal with the human side of things. All of the talks, and training courses really cannot prepare you for a lot of these things. I remember when I became a manager, I was dealing with so many issues my head was spinning. Then I took courses like Mastering Supervision which only made situations worse because I tried to use some of my new found knowledge. Some things worked, others failed miserably. Things that I learned from the IT Leader's Program (ITLP) were actually more useful. Having a coach like Brian McDonald (MOR Associates) really was another big win for me. So know you are probably concluding that being a manager now is great. Well not really...

I truly do miss the good old days. I am finding that most of the software that I write these days is of the maintenance variety. Trust me folks that is not really Software Engineering. About the only new software I have written lately was helping my kid write some Java for her class. The reality is, I'm not the only one feeling this way. I have friends outside of Penn State that are still doing maintenance on software they wrote 20 years ago. I did that maintenance type of work at Raytheon for about a year and then resigned. I'm not saying that type of work is not important. Maintenance work keeps machines moving and airplanes flying. So what I am saying?

Well, I personally missing the days of being a technical lead and having the ability to write new exciting software. Do I see opportunities for something like that in the future in my current job? I am not sure, that's the truth. I do enjoy having the ability to blog about issues like this and I'm guessing there are other "IT Managers" out there that feel the same way. Will I leave because of this? (dead silence)

I know a good friend of mine, told me I was nuts for going doing this route of IT Manager. At that time, I really did not believe him, because the glory and the prestige of the title of manager was in front of me. Now if he would make that comment again, I would probably agree with him. Oh to yearn for the good 'ole days.

Reality Check Time!

Wed, 06 Feb 2008 07:26:35 -0500

Hello...

Its been a while since I have had time to do a posting. Actually, I really do not have that much time this morning, but I figured I would get something out there. For me these days, I'm dealing with lots of projects (blogging server, FPS, Workflow, Departmental Identity, IAM, ITANA, and so on). So lots of things are happening at work these days. Actually in the future post, I will attempt to dissect what happened with the FPS outages. Its a very good example of just bad a software failure can be. But like I said, that's for a future post.

Today's topic is about a reality check. A check with what you might ask? Well, with development of a software application. As of late, I get invited to a number of meetings about a variety of projects. Most of the time, I sit in the back and just listen. Listening is a really important skill and trust me it took a lot of time to hone that skill. Of course going to the IT Leaders program and having a great coach really helped too.

Anyways, so I sitting in the meeting, and I hear things like:

"Well let's just scrap what we have and rewrite it"

"We can do this in 2 months right?"

You get the idea right? Most of these are prime examples of problems that face people in industry too. So what do I do? Well, I am typically, but not always the voice in the back of the room saying "Reality Check Time People!" You cannot rewrite a complex software application with dependencies on software that either

a) does not exist

b) does not work

You just cannot do that, actually you can but your results may not be what you want them to be. A lot of people feel that I am dinosaur when it comes to software development because of many of the ways/processes that I promote. Maybe I am. Coming for a structured world like the defense industry has really taught me a lot about developing software. Yes, I know process is important and I'm not advocating that everyone do full specs for tiny web apps that a couple of people use. However, you need to do something. We are actually using aspects of Agile Development with WebMail. We have been doing that for a number of months now. How's it working out? Pretty good actually. We have really short development cycles and I feel we are pretty out a really good product.

So back to the topic of this entry, the reality check. As developers, web professionals, managers, and so on, you have to ask yourself when you are in one of those meetings, just whether the tasks at hand are do-able. Do a mental reality check of the knowns in your own mind vs. what you are hearing. If stuff does not jive, try to express your point in a very constructive manner. Keep in mind that maybe you do not know all of the knowns from everyone else's point. But, hey that's good too. That opens up another key aspect of process, communication. People need to learn to communicate more. So ask questions, but again doing in a manner that is constructive and helpful to the entire project.

What's next? Well more entries when I get a chance (I hope). There are some topics of could be touchy, that I will tackle. One of them will be my take on a blog posting at Coding Horror a while back about making developers managers.

Testing For Affect

Tue, 30 Oct 2007 07:32:28 -0500

There were a number of movies about war that I have watched and they always used a statement "fire for affect". And in most cases when someone said that, you could expect to see some serious explosions. So what about testing for affect? I suppose if you do some and its done right you could see the same. What a minute! You do not want to see things blow up in your face or do you? Well you are testing right? So the purpose of the test is to fully exercise all facets of your application. So some bad things may happen along the way. I have been a big proponent and user to test coverage analysis tools like gcov and tcov. These tools enable you to find the holes in your testing procedures. They pretty much all work the same, you compile your code with a flag to indicate that you want to do test coverage. Then you go off and run through your test procedures (you have these right?). Once you are complete, you run the analysis tool and it adds comments to your source code file to indicate what items were tested. In addition it give a test coverage percentage. The higher the percentage the better job you did in testing. At my old job, our code have to obtain a minimum score of 85% (then it was 90%) to be accepted for integration. Now, I know things like this seem ancient to some of you folks. But they do have their place in higher ed just like they did in the defense industry. Writing good solid code is only part of the equation, you must make sure its tested well (testing for affect that is). That is why tools like test coverage analysis and testing frameworks exist to help you make sure you are putting out the best, fully tested product.

TechForum 2007 10/2-10/4 Indiana

Fri, 05 Oct 2007 09:03:54 -0500

Well after some interesting travel adventures back and forth, I'm finally in the office after TechForum 2007. The location was Indianapolis, Indiana and the weather was really nice. There were about 200 attendees total at the conference and of those there were 27. Here is a link to the site. So this entry will discuss some of the sessions that I attended. Most of them were on the IdM track. I really wanted to go to the ITIL sessions but could not make those. I will be blogging about ITLP in the near future.

Keynote

The keynote speaker was Brian McDonald from ITLP fame. Brain gave a great interactive talk about leadership, and being leaderly. To me, it was an excellent refresher. I had the correct answers when I was called upon too, which worked out well. Most of Brian's content was from our lessons on ITLP.

Affiliations and Lifecycles

This was a concurrent session of three presentations. Renee Shuey from Penn State was the moderator for the three presentations. The first topic was Enabling Lifecycle Access for Alumni. The presenters were,

Alan Walsh
Manager, Identity Management Systems
Indiana University
Duane Schau
CIO, Indiana University Alumni Association
Indiana University

They started off with some background, Indiana University has nine campuses. They have a total of 99,122 students with about 30,000 faculty and staff. Their alumni community is about 500,000. They are using a product called Identity Lifecycle Manager from Microsoft. For Web SSO, they are using Active Directory.

A student has an extended life cycle. From graduation they are kept active in the system for up to 5 years. They found that this is time that students would need to continue to interact with the University for things like transcripts. In addition, their peoplesoft system will only keep them in there for 5 years. However if you owe money to the University, you will stay in there until things are paid off. During this period in the lifecycle they maintain a very limited access. They loose their access to printing, to library services and email. They can still log onto their portal, because they keep their active directory account.

As an alum, they are able to gain access to a system called Windows Live, which provides HotMail, Chapter information, Messenger and blogging. They maintain their identity for. One thing they have which we do not is a unified name space. We have Access Accounts and FPS Accounts, they just have one. The contract that they have with Microsoft states that they M$ will not mine the student data. They give students 6 months to transfer their email to the new system. In addition, they are looking at outsourcing options for student email at this time.

The next topic was Delegated Identity Management by:

Tom Board
Director, Information System Architecture
Northwestern University

Tom's definition of an affiliate not represented in the HR or student databases. Some of the services they will be accessing include: library, email, authentication, ssl-vpn, presence within the AD forest.

Some examples of these affiliates include a donor, contactor or co-pi at another university.

At Tom's school they do delegated identity management, they have a system that enables to dean's office to create and manage identities. How about that one? In addition, they do not use student staff for identity proofing. They are another school that uses Active Directory. One of the most important things is visibility in their directory.

And the final topic was Managing Visitor and Community Access by:

Chris Clark
Manager, ITC Support
University of Iowa

This one was pretty cool from a software perspective in that they did an Agile solution for their problem. This is so so cool. They focused on an immediate need how to give, wireless access, and public computer access to people. Immediate access is one of the requirements along with extensive logging. This is very similar to our STAA process. They are using 802.1x for wireless. Their system is web-based and creates ids in Active Directory. Access is controlled via AD groups.

Vended vs. Open Source Perspectives on IdM

This one was another great session, it was moderated by Tom Barton (Chicago). One presenter represented COTS and the other Open Source.

Matt Kolb (Open Source)
Identity Management Coordinator
Michigan State University
Monica Crawford (COTS)
Developer
University of Wisconsin-Madison

Monica gave an overview of UW, they have 13 campus locations that do a four year program and another 13 that do a 2 year program. Their ldap directory has over 1 million entries in it. Because once people have an affiliation they never leave the directory. From a technology side, they are using Sun ONEs system. The directory grows by about 80,000 year. The ldap directory is used for authorization.

Matt was on the side of open source. They have one campus location and about 40,000 students. They have a total of 164K accounts. They are using one name space for their accounts, this has been in production since 1993. Their system was created by the needs of their email system. They are using Kerberos V and LDAP. They are working on a real-time account provisioning system that will be open source some time. From a directory standpoint they are looking at opends. And they are using shibboleth both internally and externally.

Revision Control

Fri, 14 Sep 2007 07:41:34 -0500

So you have this great application that you have written and you want to make a tiny change to a source file. What do you do? What happens if you change does not work? Valid questions all of them. When I was at Raytheon, I used to watch seasoned developers do a practice that was not very good. Anytime they wanted to make a change, they would copy the current file to a new file and append the date onto the end of it. After a long time they would have a large number of files in their directories with all of these dates on them. Problem is they had no idea what they did or what bugs they had in them. What a mess! Sad to say, I still see things like this going on.

So what do you do? Well use Revision Control of course, hey that's the topic of today's posting. Revision control is a software application that allows you to maintain multiple versions of a source code file (at its most basic level). There are a number of tools out there to accomplish this task and which one you select will depend on the platforms you are using and the size of your project. Some of the major players include SCCS (Source Code Control System), RCS (Revision Control System), CVS (Concurrent Version System), and SVN (Subversion). All of them have their good points and weaknesses.

Stay away from SCCS, it is extremely cryptic in its command use. We used it for a couple of projects back at Raytheon and it was painful to use. RCS is much nicer, and the command set is pretty brain dead simple. You want to check in a file you use ci, to check it out use co. The downside with RCS is your are dealing with single files, not entire projects. So if you wanted to check a project tree in for example (under UNIX), you would have to do something like:

for i in `ls *.c`

ci -u $i

done

Ugh right? But hey at least your are using something. Subversion (SVN) is a much better solution for teams, since it supports the concept of checking in/checking out entire project trees. Again, you can find more information about it by doing a simple google search. Right now we are using SVN for most of our projects and RCS for our configuration files (like httpd.conf for example). CVS has been around for years like SCCS. It has the same type of support for project trees. Again, do a google to find more information about it.

The key thing to remember with regards to revision control is to actually do it. Do not get into the habit of creating copies of files and appending dates on the end. Oh yeah, another point to remember is all of these tools support the concept of a log message. This is some descriptive text about what this new version of code represents, new features, changes and so on. I have seen people embrace RCS/SVN into their environments and when it comes time to do the log message, they enter a single word, UPDATE. Now, that's not really helpful is it? How is the next developer who has to look at that code going to figure it out? Well, probably spending a lot of time with a diff program.

Key Points:

Revision control is extremely important to a solid software development process.
Select a tool that will work with your environment.
Popular systems include: SCCS, RCS, CVS, and SVN
Be descriptive when you enter your log messages.

My Daughter's Homework

Thu, 06 Sep 2007 07:13:47 -0500

For those of you who are forgetting, I entered into marriage with Sheri Vail (now Sheri Vuccolo) on May 5, 2007. Sheri had two children, Courtney and Tyler. Our daughter, Courtney is going to Penn Tech in Williamsport where she is a senior in an IT major. She will have her Bachelor's next year. Anyways, she is working on her senior project. The aim of which is to develop an application from the ground up using everything she has learned during her past three years of schooling. It is a very interesting activity. The reason that I am writing about it, is she showed me a copy of a questionnaire she had to fill out before she could submit her project idea. I found the questions to be extremely interesting, in that they really have broad application to some of the process work that I and others are trying to do at Penn State. So I acquired a copy of her homework questionnaire and decided to post it for comment. I'm going to fill it out using a project I just completed, so you get an idea of how useful it can be. So here goes:

State the name of your domain (for our purposes this would be our problem area). - My domain is protected web space.
What, at this moment, do you plan to do in this domain? - I plan on developing a solution for students/faculty and staff to be able to indicate certain web-content as restricted.
What tools are you thinking to use in your project? Since the project is web-based, it will use our enterprise file system, Perl, HTML, JavaScript and CSS.
What possible problems or difficulties are you thinking about which may obstruct your smooth development of your project? - I would have to say lack of time and resources.
At this moment, how do you wish to handle these problems stated in #4? - Well, I plan on re-using existing designs, farming out as much as I can to other capable personnel.
Why did you choose your domain (problem area)? - In my case the problem area was chosen by outside forces.
Do you plan to work further in the project in the future? Yes/no.
Who and how large will be the population that will be affected with your project? - The university at large.

As you can see, Courtney's first assignment really makes you think about your project. It asks those basic questions: Why are you doing this project? What is the project? How do you plan on solving this project? When will you have things done? Of course there are other valid questions to be asked as well. Two key points to be remembered about all of this:

Ask the questions or be ready to answer them.
Write done your answers, preferably in a tool like a wiki.

So I imagine, I will have further updates on how this little project is coming along. I have a couple more good posts in the works, that I will get out there as soon as possible.

Links for the week ending, August 24, 2007

Fri, 24 Aug 2007 07:38:29 -0500

Here is another batch of the weekly links, enjoy.

What is modern software development? Another great article from Coding Horror about modern software development, its a very quick read actually its a checklist.
How JavaScript is slowing down the web (and what to do about it) - A simple little scripting language can cause major problems for users and ISPs. Read about how you can do things to avoid problems.
Agile Data Page - home to all things Agile.
Agile Modeling Page - another great Agile resource.
Agile Testing - how do you test when you are doing agile? Read this page to find out.
Agile Advice - new to Agile, then you really need some advice on how to implement it.
What first time IT Managers need to know? The subject pretty much says it all.
Leading by example - How to lead to a software team.

Have a great week/weekend!