We’re working on our next meeting, so stay tuned.

In the mean time…

Make sure you check out these other two meetings that I’ll be at, and I thought might be interesting to you as well!

EVENT 1:
The Agile Enterprise (A TechLife Columbus meetup)

February 11th, 2010
4:00 PM – 7:00 PM
(Sorry for the late notice.)

Price: FREE

Dublin Entrepreneurial Center
7003 Post Rd.
Dublin, OH 43016

Click for more information & to RSVP for The Agile Enterprise

Summary:
This will be a recurring meetup series, oriented towards large organizations and growing organizations. Everyone is welcome.

These meetups will follow the OpenSpace/ Unconference format – meaning, come prepared to participate! There will be no presentations nor handing-down of platitudes! Participants will share their experiences, challenges and successes. Everyone’s input is valuable; Everyone has something to learn and something to teach.

Topics will rotate and be chosen by the participants, to discuss issues such as:

* How can a growing organization stay agile, yet implement the discipline necessary to scale and survive?
* Innovation and agility of a startup, within a large enterprise
* How much process?
* Making cultural changes
* Moving the needle when you’re in the trenches
* Getting support from employees when you’re making changes from the top
* Knowing what needles to move and knowing when you’ve made a difference

This month, we will attempt to focus on practicing agile development methodologies in a large organization. What methods do not scale and how do you adjust?

EVENT 2:
COHAA Day In The Life Tour: Progressive Medical

February 25th, 2010
7:30 AM – 9:00 AM

Price: FREE, but limited to 15 people. You must RSVP here.

Progressive Medical
250 Progressive Way,
Westerville, OH 43082

Click for more information & to RSVP for the COHAA Day In The Life Tour: Progressive Medical

Summary:
Host: Ben Blanquera, VP Information Services

Due to limited space, RSVPs are limited to 15 people. Please only RSVP if you are attending.

Please join COHAA as we take a tour of Progressive Medical’s Agile space. Come learn ‘Why Progressive Chose Agile’.

Ben Blanquera is the Vice President of Information Services for Progressive Medical, Inc . In his role, Ben is responsible for project/portfolio management, application development, business intelligence, and business analysis.

Progressive Medical, Inc. is a nationwide, managed care and health care cost containment company. It coordinates care for workers’ compensation, auto-no-fault and personal injury protection cases. Progressive Medical is a Inc. 500 Hall of Fame company.

I hope to see you there or at the next EAIA meeting!

Stay warm!

Technorati Tags: agile development, eaia, enterprise application integration, techlife

Technorati Tags: agile development; haiku; code refactoring

1500 Lines of Code

This really got me thinking, and I’ll probably work on a comment to it this week.

Technorati Tags: c++, java, php, software architecture, software development, web development

We are currently looking for speakers and topics. If you have EAI experience, successes, failures, or lessons-learned, please let me know!

Thanks!

Technorati Tags: columbus, enterprise application integration, meetup, message oriented middleware, service oriented architecture

TechLife LinkedIn Profile – Kris Hardy – Software Evangelist

Technorati Tags: linkedin, techcolumbus, techlife

Subversion is a version control system. It can run as either it’s own server (svnserve), or as an Apache module (mod_dav_svn.so).

When using the mod_dav_svn module for Apache, and doing an svn copy operation on the repository itself can fail if the VirtualHost configuration for subversion is not correct. Put simply, if Apache itself and mod_dav_svn are serving content from the same path, then conflicts can occur. Apache can get confused if it attempts to serve a physical file instead of routing the request through mod_dav_svn.

“svn copy …” operations will fail, while “svn update …”, “svn commit …”, and “svn checkout …” operations work fine.

Detail of the problem, diagnosing the problem, and the fix are below.

Problem

Repository checkouts (svn co …) and commits (svn ci …) work fine and throw no errors, but svn trunk copying operations fail “svn copy …/trunk …/tags/x.x” with “svn: Repository moved permanently to ‘…’; please relocate”.


$ svn co https://svn.test.com/myproject/trunk myproject
... (checkout progress)
Checked out revision [x].
$ svn ci myproject
Committed revision [x].
$ svn cp https://svn.test.com/myproject/trunk https://svn.test.com/myproject/tags/x.x
svn: Repository moved permanently to 'https://svn.test.com/myproject/'; please relocate


Diagnostics

To diagnose the problem, first make sure the local checkout urls are correct.


$ svn info myproject
...
URL: https://svn.test.com/myproject/trunk
Repository Root: https://svn.test.com/myproject


The Repository Root should match the root url of the project repository that you are working with because the svn commit above worked. However, if they don’t match, then use svn switch to move the url that your local checkout is linked to:


$ svn switch --relocate [OLD URL] [NEW URL] myproject
$ svn cp https://svn.test.com/myproject/trunk https://svn.test.com/myproject/tags/x.x


If relocating the base url of the checkout (svn switch –relocate …) does not fix the problem, but checkouts and commits work fine, the next step is to look at the virtual host configuration in Apache for the subversion module. This is where I found my problem.

Fix

The file path of the subversion repository was within public_html, so it had a physical path that was identitical to it’s url path.


$ ls public_html
repos
$ cat /etc/httpd/conf.d/subversion.conf
<VirtualHost 127.0.0.1:443> #YOUR IP ADDRESS:PORT
DocumentRoot /home/svn/public_html #YOUR WEBROOT PATH
...
<Location /repos>
DAV svn
SVNParentPath /home/svn/public_html/repos #YOUR REPOSITORY PATH
...
</Location>
</VirtualHost>


The problem is that the Location is an actual physical filepath, not an alias. So, Apache isn’t sure whether to attempt to serve the physical file itself, or to pass the request through to mod_dav_svn. Most of the time mod_dav_svn wins and Apache forward the request through. However, “svn copy” must work slighly differently, and Apache attempts to serve the request itself, rather than pass it through mod_dav_svn. The request then fails and svn errors out with the “svn: Repository moved permanently to ‘…’; please relocate” message.

The fix is to 1) change the Apache configuration, and 2) change the physical path to the repository so that it does not match the url. This way, Apache will never attempt to serve a physical file itself, and will instead forward the requests to mod_dav_svn.

Edit /etc/httpd/conf.d/subversion.conf


<VirtualHost svn.test.com:443>
DocumentRoot /home/svn/public_html
...
<Location /repos>
DAV svn
SVNParentPath /home/svn/repos #NOTE THAT repos IS NOW OUT OF THE PHYSICAL WEBROOT PATH
...


Move the repository directory out of the physical webroot path and restart Apache.


[svn /home/svn]$ mv public_html/repos .
[svn /home/svn]$ sudo service httpd restart


All your “svn copy” operations should work now.

Technorati Tags: apache, repository moved permanently, subversion, svn copy

Problem:

A large PHP application that I have developed at Submerged Solutions (SandPiper Accounting) began throwing Permission Denied (13) system exceptions when attempting to send mail through Zend Framework’s Zend_Mail library.

All the phpunit unit tests worked fine and could send e-mail, but would fail when the usability tests started and any HTTP requests that sent e-mail were handled through Apache.

The Apache instance was being run as user apache / group apache, and php (mod_php) is run as user apache / group apache.

The exception occurred in Zend_Mail_Protocol_Abstract->_connect(), immediately following the socket opening call “stream_socket_client(…)”.

File: Zend/Mail/Protocol/Abstract.php; Line 224

50: abstract class Zend_Mail_Protocol_Abstract
51: {
...
218: protected function _connect($remote)
219: {
220: $errorNum = 0;
221: $errorStr = '';
222:
223: // open connection
224: $this->_socket = @stream_socket_client($remote, $errorNum, $errorStr, self::TIMEOUT_CONNECTION);
225: ...


fopen() calls using http and ftp protocols also failed:

Warning: fopen(…) [function.fopen]: failed to open stream: Permission denied in …

The fix:

The problem turned out to be the “httpd_can_network_connect” SELinux setting that is on by default in Fedora 12.

In a shell console, run as root:

# /usr/sbin/setsebool httpd_can_network_connect=1


Thanks to durwood, who pointed this out on PHP.net.

“Bug” Report at RedHat.com.

More info on SELinux.

Technorati Tags: apache, Debugging, permission denied, php, selinux, stream_socket_client, zend framework, zend_mail

Before I began developing software for a living, I used to be in chemical research & development as a biochemist.  For some reason, I always found myself gravitating back towards software and informatics, so I eventually gave in and started a software company.  But I’ve learned a lot of lessons during my time as a scientist.

When solving a difficult problem and you know 25% of the solution, you can figure out 70% through hard work, patience and trial-and-error.  The last 5% may never come, and if it does, is rarely when you’re looking for it.

“I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world.” – Albert Einstein

Just because you don’t know the answer right now, doesn’t mean that you can made headway and figure it out as you go.  I’ve learned the most when I’ve tried things that haven’t worked, but figured out what went wrong and then tried again.

If you’re not continually learning and improving yourself, your working days are numbered.

“Genius without education is like silver in the mine.” – Benjamin Franklin

Don’t be afraid of challenging yourself and learning new languages, technologies or skills.  Each one of them expands your experience and perspective, and can give you an opportunity to take a look at the status quo.  Unfortunately, self-motivated learners are in short supply but in constant demand because they can adapt to any situation.

If you want to succeed, you have to train for it.

“You can know the name of a bird in all the languages of the world, but when you’re finished, you’ll know absolutely nothing whatever about the bird… So let’s look at the bird and see what it’s doing — that’s what counts. I learned very early the difference between knowing the name of something and knowing something.” – Richard Feynman

Let’s face it…  The likelihood that you’re going to “knock one out of the park” your first time up to bat is pretty low.  Whether it’s business or baseball, the odds are against you.  It takes grit, determination, exercising yourself both physically and mentally, and lots of disappointment as you fail again and again.  But each day, train yourself a little more, a little harder, and each day you get a little stronger.  It’s cumulative, and it takes a lot of time.

Give credit to those who came before you.

“If I have seen further it is by standing on the shoulders of Giants.” – Sir Isaac Newton

In science, recognition is incredibly important and one of the first lessons that you learn.  When you’re making a presentation, writing an article, or doing your homework, you have to cite any sources of information that when into your work.  This is partly because scientists are focusing on sharing knowledge, and in order for the community to work together, there has to be trust between researchers that their information will not be stolen by one-another.

Even more so, no inventions are made in complete isolation.  They are incremental improvements based on our understanding of our world and everything that has come before.  The iPhone wouldn’t exist without the much earlier inventions of silicon wafers, transistors, plastics, aluminum, and light.  And the next wave of inventions will be no different.

Take advantage of the information and knowledge that we have, but show respect to the community that this knowledge came from.  You probably will need more help from it in the future.

Technorati Tags: education, einstein, feynman, newton, problem solving

Before I get too far, let me give a quick overview of Scrum:

Scrum development is a business process that seeks to speed up development, decrease bugs, and increase the quality of products that are delivered.  It doesn’t have to be focused on software development, but that’s where it has the greatest pull right now, and the use that I am going to focus on.

Scrum, at least how we use it (mixed with Extreme Programming), uses several key components:

• Iterative and Incremental Development – A product is released after each “Sprint” (typically 1-4 weeks).
• Test Driven Development – Automated unit tests are created to test the code, databases, and user interface.  For PHP, we use PHPUnit and some in-house database testing tools.  For Java and integration endpoint API tests (regardless of language), we use JUnit.
• One-Touch Build, Document & Deploy – Automated build and deployment sequences are developed to reduce variables, problems and time.  Ant is a great tool for this.
• Continual Integration – The software is compiled and thoroughly tested nightly (and as needed) throughout the sprint.  CruiseControl is useful for this, although you can also do something as easy as schedule a nightly cron job to execute an ant build file.
• Source Version Control – We use a central version control system (Subversion), to manage our code.  This allows me to work from multiple computers on the same code (such as when I’m traveling), and it also allows me to work with other developers when I’m partnering or outsourcing work.
• Product Backlog – Stories and feature sets that our customers want in the software that haven’t been completed yet.  Prioritized by business necessity.  I’ve heard good things about XPlanner and Pivotal Tracker, but we’re using simple index cards.
• Sprint Backlog – Stories & feature sets that we will complete during a sprint.  Negotiated between us and our client.  Here, we feed the index card stories plus any information from our client into (dotProject).  It’s not fancy, but it’s working for us today.
• Sprint Review – Lessons learned, what went well, and what didn’t go well.  Also, client’s likes/dislikes of the last product release are included.  We use a wiki for this, such as MediaWiki or dokuWiki.

A typical Scrum team consists of:

• Product owner – Your point-of-contact, who is responsible for the project.  Usually a Business Analyst or Project Manager.
• Users - The end-users, commonly the client’s staff.
• Stakeholders - Typically, these people are the client-side Project Managers and are the ones that are paying for the product.
• Scrum Master – The member of the consulting or development team that is responsible for delivery of the product.
• Team members – The actual development team

Things get really interesting when you start looking at roles for Micro-Scrums.  When you are running a Micro-Scrum (such as if you are a lone consultant), the scrum master, team members and product owner are consolidated to a single person (you).  And when your client is a small business, your contact ends up filling multiple roles, so your actual Scrum roles look more like this:

• Scrum Master/Team/Product Owner (Consultant)
• Stakeholder/User (President, CEO, or General Manager, etc.)
• User (Client’s Staff)

Consolidating those roles makes things both easier and harder at the same time.  It’s a bit easier because there are fewer people that you need to communicate with.  It also makes things more difficult because I, as the Product Owner, now don’t just need to make sure that the product is developed and delivered.  I also need to fill the roll of a Business Analyst, so I need to understand the business case, consolidate all the user’s needs and prioritize their importance.

I also have to avoid focusing on my own “pet features”, which developers can sometimes do, and instead have to focus on what will bring my client the greatest value in the shortest amount of time.

Now that I’ve mapped out the landscape and I’ve distilled all those roles down to 2-3 people, let’s get into some details…

Starting a small-business development project as a Micro-Scrum involves a lot of communication.  In my experience, clear communication will make the greatest impact on the success or failure of a project.  There needs to be a very clear understanding from both the client and the consultant on what is going to happen and how the product is going to be developed and delivered.  If you are on the same page and can negotiate the priorities, things work well.  When your client can’t understand the iterative mindset and he wants it all done right now without prioritizing, it’s a lot more difficult.

Here are some lessons that I’ve learned the hard way:

Lessons Learned

In Micro-Scrum, the focus needs to be on quality, NOT on cost.

All too often, small Agile studios like mine are compared to freelancers or overseas developers on sites like Elance and Guru.  The bottom line is that we cannot complete with their hourly cost, so we don’t even try.  What we focus on is Quality, above all else.  Unit-tested code, usability & acceptance tests, code reviews, security audits, and active communication with our clients throughout the entire process.

It has worked well for us, and we’ve kept our current clients for nearly 2 years at full workload.  The past year has been our best year ever, despite the recession.

Micro-Scrum development usually costs more, initially, than methodology-less development (aka cowboy coding).

This goes along with the previous lesson.  The up-front costs are usually higher, however the bug rate is much lower and the documentation is better.  Also, the risk and time involved when refactoring and modifying the code is MUCH lower.  Software changes are anticipated, so we develop with that in mind.

When working with a new client, deliver early and often.

When working with non-tech-savy businesses, keep the sprints short.  We like to do 2-3 day sprints at the beginning to get them accustomed to the process.  Even if that means just delivering them a framework, some raw code, a library or sketches, it pays off dividends over the course of the project.  It opens up communication and makes sure that our direction matches their vision.

In addition, you get to run through a deployment dry run each time.  If you notice problems in the process, you can fix them early on rather than waiting until the end and being surprised that their server doesn’t support a dependency that you built into your software.  (It may sound silly, but it happens.)

The risk with this rapid iteration is that if you don’t explain why you’re doing this, your client may feel like you just don’t understand what they want.  And they’d be right.  The entire purpose of these short sprints at the beginning is to learn what your client wants by giving them something tangible that they can critique and use as a reference.  That tangible prototype can help you understand what they really want.

Keep the up-front requirements gathering as short as possible.

Feel free to post flame-comments below. 

What I’ve run into many times is that clients don’t always know how to explain their vision and be clear with what they want.  For about 1 full month back in 2008, I beat my head against a wall because one of my clients seemed to contradict their needs on a weekly basis with an accounting system I was developing for them.

I decided, out of desperation, to cut the requirements gathering short and push forward with what I had at that point.  Amazingly, I was pretty much right.  After Sprint 1, there were some modifications and changes, of course, but I was able to hit the target with only about 30% of the requirements being known up-front.  In addition, it forced us to build a very flexible architecture so that we could easily adapt to the unknowns and changes when we hit them.

What we do now is start with a very quick Sprint 0, maybe a week at most, and build the user stories, initial specifications and product backlog.  There will be lots of unknowns and changes later on.  Managing and working around those is just part of software development, especially when you’re working with companies that don’t understand software development.

Failure is GOOD!

This may seem counter-intuitive, but failure is a good thing.  It opens the lines of communication for constructive feedback.

Our goals with all our projects is to “fail fast.”  What that means is that we deliver a product in an early iteration (ideally Sprint 1) that our client will see lots of problems with.  Maybe the interface doesn’t meet their needs, or the work flow isn’t intuitive.  Whatever it is, I actually want my client to come back to me and say “I don’t like this.”  I then ask them “What specifically don’t you like?”  Or my favorite: “Let’s do a screencast and you can show me what’s happening.”

Take each failure as an opportunity to open the lines of communication even further.  Learn exactly what your client wants by watching him or her use your application.  Developing a Micro-Scrum team takes time, and building the relationship and trust through open communication is essential.

I’m sure you’ve noticed that communication is a common theme in Micro-Scrum.  Actually, it’s really the primary driver behind Scrum and any other Project Management methodology.  In order to deliver what a client wants, you need to have clear communication to truly understand their needs.  In my eyes, there is no other way to deliver a successful product.

Scrum formalizes the communications and works to get everyone, from the users and stakeholders to the developers, engaged in the success of the product.  When you are Micro-Scrumming, this communication becomes even more vital since there are fewer people involved and more responsibility on each person.  Harnessed wisely, it can lead to very successful projects that have good short-term value and outstanding long-term value.

If you’re in the Columbus, OH area and want to learn more about Agile Software Development, I highly suggest going to the Columbus Ohio Agile Alliance (COHAA) meetings and getting involved in TechLife Columbus meetup group.

Technorati Tags: agile, junit, microscrum, phpunit, scrum, submerged solutions

At it’s essence, Bootstrappers are business owners that start and grow their business without any outside funding. That means no angel investors and no VC deals. You don’t hear about it much because it’s not glamorous, but it’s the way that most businesses are started.

I am a hard-core believer in bootstrapping, and I know for a fact that I have learned a lot of lessons the hard way that I wouldn’t have learned as easily if I had not been a bootstrapper. (Mo’ money, mo’ problems anyone?)

Especially when you start your first business (and if you’re like me, your second as well), you WILL make mistakes, and lot of them. I still make mistakes, but I like to think that my hard-fought experience has saved me several times. Sometimes I can get out of the way in time, and sometimes I still get run over. But I’ve become better and better at keeping the damages small and keeping the business agile.

If you’re in the Columbus, OH area, come out to a meeting of the International Bootstrapping Association and say hi!  Our next meeting is Dec 9th, 2009 at TechColumbus hear Ohio State University.  RSVP at the link below:

http://www.bootstrappingassociation.org

Technorati Tags: bootstrapping, business development, columbus ohio