Monday, July 28, 2014

New FoxShow Episode featuring Southwest Fox 2014 Organizers

The latest version of the FoxShow (FoxShow #79 - Southwest Fox and Southwest xBase++ 2014) features an interview with Rick Schummer, Doug Hennig and Tamar Granor about what they have planned for this year's Southwest Fox conference, fast approaching in October.

If you haven't registered yet, be sure to listen for a special offer from Rick in the show.

Hope to see you there!

Friday, April 25, 2014

Timetracking and Cool Tool Alert: SonicAgile Project Management


   
Sometimes a blog post talks about a tool and it sounds like an ad. Othertimes, it provides good information and then it mentions a tool. Such was the case when I read this post from Stephen Walther.

The explanation of time-tracking (second paragraph) really hits home when trying to promote why it should be used. I've been working with Microsoft's TFS for the past few years and one of the challenges has always been getting people to track time. If they don't see a real benefit to it, it's often perceived as a negative performance measurement tool. They have to get over that mindset.

As the post says "the Product Owner needs to know when the work on a story has gone over the original time estimated for the story. The Product Owner is concerned with Return On Investment... a legitimate reason to halt work on the story and reconsider the story’s business value."
"if your team is spending 75% of their time doing testing then you might need to bring in more testers. Or, if 10% of your team’s time is expended performing a software build at the end of each iteration then it is time to consider better ways of automating the build process."
The post then mentions SonicAgile, which I had never heard of. SonicAgile is a new online Agile Project Management and it is really really great. I've run through the gamut of online project management tools- from Basecamp, Kanban Kit, Trello, TFS, among others. All of them are great tools and depending on the client, I still use them.  KanBan and Trello use the card-style interface and it's such a great way of forcing users to stay focused, even Microsoft turned to using a similar approach in TFS 2013.

SonicAgile uses a similar interface - but focuses on making project management super easy. After going through challenges with introducing agile processes, the fact that you can turn concepts (like iterations or epics) on or off can make this very useful for experienced or new teams!
 If you're tracking multiple projects and/or different teams, you can turn on features just for specific projects.

Just getting started? Keep only the basic idea of using Cards to track features, change requests and bugs from To Do, In Progress and Done, just like Trello.

Need Iterations? Turn on the feature and now you can group your cards into time-sensitive Iterations.

Need Epics? Just turn them on.



Another cool feature - Roadmaps. You can create a public roadmap (much like Lianja did during its beta cycles) and use it for planning your iterations.

 Oh yeah, on the road but without browser access? Just email your user stories to a special email address and it will create the cards for you.

 It's a new tool - so I'm excited to see where it goes (it needs a mobile client) - but right out of the gate, SonicAgile got a number of features (including scheduled reporting) that are right there when you need them.


Thursday, September 05, 2013

VFPX Open Source Treasures

I mentioned this on the latest FoxShow episode but also wanted to note it here.

If you go to Get VFPX , the price of the new book says it's $59,99 but if you actually click on the "Buy Now" button, you should be able to get it for $49.99 before September 6th.

Saturday, August 17, 2013

Here, There and AlphaAnywhere

I had a great conversation last week with Richard Rabins from AlphaSoftware.  Long time Fox developers might remember Alpha 5 - that's the same company but they now have an offering called Alpha Anywhere which is a fast way of generating HTML 5 based solutions for web-based and mobile based solutions. Before you think about "yet another HTML 5 App generator", while you can do client-side javascript, you can also do server side scripting with their language, which is very similar to VFP.  They've also got a fairly well known CTO, Dan Bricklin (of Visicalc fame). He's done a lot of "native" development for iOs and various platforms so it's interesting for him to jump into the full HTML 5.

They have a demo version you can look at to get started but are also filled with lots of AlphaAnywhere.

I'm going to be publishing our talk in a FoxShow next week but one of the great things for Fox developers is that he's hoping to be at the SW Fox conference in October. Sounds like there's going to be a lot of HTML 5 being spoken at SW Fox this year.

Update: The show has been posted here

Sunday, June 16, 2013

Why VFP Developers should look at SW Fox 2013

For 10 years now, the Southwest Fox conference has served as a great gathering for FoxPro developers, looking for insight, ideas and inspiration on moving their development applications and skills forward. Over the years, there have been spotlights on moving VFP applications into the cloud, onto mobile, integrate better with .Net and lots of other technologies.

While Visual FoxPro isn't receiving internal code updates from Microsoft, Visual FoxPro (or VFPX) continues to grow into a larger tool in the developer's arsenal. While Thor continues to deliver more power in the actual FoxPro IDE, new interface features grow what FoxPro applications can actually do.

But the core of FoxPro (fast and efficient database access) remains - and for all the tools or applications provided with Oracle or SQL Server or Postgres or whatever, VFP still provides the best data access environment that I've ever worked in. That means for developers who still need to deliver solutions, VFP will still be in demand. It may not be the "development language" for the next application nor will the DBF be the database - but the concepts behind accessing data and the extensibility keeps the product compelling.

How is that possible? When you run software in a corporate environment, IT departments liked to lay claim and identify the software they wanted to support. Typically, that meant whichever software was a) sold into the department by vendors (Oracle/MS) and b) understood by the most recent IT hire. Today, the corporate world has evolved - it's run more efficiently. People don't care as much as what software is developed in or with, they care that it works. That's not to say, they didn't care before - but I've seen government departments spend four-five times as much on new development to replace an older working technology and STILL not get the same result. Now the focus is on efficiency. If someone had told a corporate department that they would be running with a free database server 15-20 years ago, they would have been escorted politely out of the room. Today, it's all about what works.

Smaller businesses (as opposed to Fortune 500/Government) has always been about what works - that's why you found the smaller tools with greater reach. I remember one of the first times I saw West-Wind Web Connection (or what was to become the web connection), it was the power behind one of the first online retailers, handling thousands of transactions with ease. I've heard rumours there are even some FoxPro DOS applications still in use today in Europe. Most development today isn't even about the latest tools -> you can write an application today in Notepad  - it's about HTML5, CSS and Javascript (check out the latest IOS7 mockup done in with just this , including icons).

At the same time, new software is constantly sprouting up. New databases, new extensions, new technologies, new cloud ideas, open-source environments, new environments ---- all of these make for exciting times for developers. SWFox also features a co-conference with Alaska Software, who have breathed new like into older Clipper applications with xBase++. In one of my sessions, we're going to highlight a lot of these new environments and how VFP developers can leverage their experience and expertise in these new tools.

Registration for this year's conference is wide open but they have an early-bird deadline coming up that ends on July 1st ($670, which includes a Pre-Con session - a steal considering some conferences are still going at $2500). Check it out at Southwest Fox 2013.






Friday, June 14, 2013

Looking forward to Southwest Fox 2013

Doug Hennig: Southwest Fox 2013 Speakers and Sessions Announced

Doug's written up some of the sessions he's looking forward to and I have to say the sessions announced for Southwest Fox cover a wide gamut for the FoxPro (and xBase++) developer. (full disclosure: I'm speaking so I'm excited about that too)

Like Doug,  I'm very excited about Eric Selje’s Will the Circle Be Unbroken: Continuous Integration and VFP

When VFPX first came about, Alan Stevens had done some work on an MS Build target for VFP. This never really took off which was too bad. Continuous Integration is so wonderful that once you have it, you will wonder why you didn't do it earlier. It's a great way for ensuring you compile, teaching your team, identifying conflicts and just feeling good about your approach.  We're using it extensively at one of my clients and it really has helped identify the culprits (gulp!) who break code.

Hope to see you there

Wednesday, June 05, 2013

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator)

So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinctions I would argue are the difference between programmers and developers.

While many advanced developers make assumptions such as "every programmer unit tests their code" or "everyone uses TTD", most developers I've ever met know that's not the reality.


Software developers write code. Software architects solve problems.

Actually, I thought it was Programmers write code and Developers solve problems. Architects build something even bigger.

That said, all of the points are valid - but I can't help but think... if developers now write code, what do programmers do? 

I see a big difference between the term "programmer" and "developer" - I know it's all semantics but it's an important distinction when hiring. Lots of people know how to "code" - technically, if you've dabbled in VBA in an Excel macro, you've "coded". Does that make them a "coder" or a "programmer" or a "developer"?

A good example might be programmers code, but developers debug. Developers should be able to see the bigger picture. Programmers can write a program - but, in my mind, developers should be able to describe the problem, identify the solution, and explain it. I've seen enough amazing programmers who can use the most arcane or bizarre ( but cool ) methods for coding a function or problem but are inept at defending or explaining it. 

But the other aspects of the newsletter have some interesting points on it.

Software developers see bugs. Software architects see the big picture.

Huh? If I hire a programmer, I expect them to fix bugs. If I hire a developer, I want them to do a bit more than that. Maybe a better way of looking at it is in scope:

Code ----> Library -----> Software Application -----> Broader Solution

I can expect a programmer to write code and maybe even an entire library. I expect a developer to be able to write/support a library and an entire application - heck, maybe even the entire solution. I do expect an architect to be a bit more than just a developer but the broader solution? I expect anyone in a more senior position (developer, architect, product manager) to get the big picture.

(now I have seen scenarios where S/As seem more focused on smaller issues instead of the big picture - but I don't want to get into a p*ssing match with Systems Analysts).

Software developers focus on the computer. Software architects focus on the customer.

Once again - I suppose you could say Programmers focus on the computer, developers focus on the solution, architects focus on the customer - but I thought that was the purpose of the PRODUCT Manager (or Project Manager). Either way, the developer better understand and get what's required. Developers should perhaps focus on their peers and ensuring they can explain what is involved.

Otherwise, don't call yourself a developer, especially if all you can focus on is the code.


Software developers think about new technologies. Software architects think about trusted technologies.

This is an interesting one. I tend to think about it in terms of "problems". Junior Programmers have a handful of ways of dealing with a problem and usually try to use them to fix a problem. Developers do (and should) learn about new technologies and see where they best apply. They should LEARN those new technologies but also be smart enough about when to use it. They should be able to evaluate those technologies and see if there's a reason to use it in the resolution of a problem.

If all a software architect did was used "trusted" technologies, does that mean they only use "proven" technologies? (in other words, the old "no one got fired for using IBM, etc" approach)

Punch cards were once "trusted" but they moved to "tapes" and then "disks" and then "optical". Which would you "trust"? It depends on your background. 

I would go so far as to say architects think about trusted SOLUTIONS, not technologies and PROVEN technologies. A solution is the approach you take to resolving a problem - the technology is what you use to implement it. 

When I got to the end of the newsletter, I started to think that it's me. Maybe it's the reason that you don't see job postings for "programmers" but for "developers" - but let's not simply evolve the definition of a programmer to a developer without making a huge differentiation between what those capabilities are.  

One other point: referring to software "architecture" can really bug traditional architectural engineers. While software may deliver a lasting solution and there are parallels between physical buildings and software, this easily overlooks a lot of issues (but that should be a different post). 

Programmers Program. Developers Develop. If you look at what an architect does in terms of requirements, it almost sounds most like systems analysis (because they often don't build it). Maybe what we really want is a "Builder" term. But then, maybe we need a "Wizard" because businesses often want software that will work "magic". 

If you've never read any of Brandon's stuff, do yourself a favor and check it out. 

What about you? Are you a Programmer, a Developer, an Architect? What's the difference to you?


Monday, March 04, 2013

Thanks for all the fish, Calvin!

Calvin Hsia, Microsoft developer and one-time movie star,  combines two posts into one to note one great tip and one tip of the hat....

1. If you weren't involved with FoxPro in the early 90s, you may think that Microsoft's MVP program was the brainchild of a marketing expert, but in fact, it came from Calvin's listing of the "most verbose people" in Compuserve's FoxPro support forums. The program is now 20 years old, despite cutting VFP out of the program. Way to go, Calvin!

2. Onto the cool tip, when .Net first came out years ago, I was asked to evaluate the conversion of a fairly dynamic VFP application into .Net. One of the biggest roadblocks was how to handle dynamic scripting. We asked around and even .Net experts couldn't come up with an ideal situation. In other applications, I've ended up using pre-compiled DLLs, loading dynamically, to achieve similar results but I've always wanted a better solution.

Calvin's solution? Using CodeDomProvider and the CompileAssemblyFromSource method. There's a little bit of set up (creating methods that return "known values" (strings, booleans, etc) - but otherwise, compile and execute your code on the fly. Genius!

Thanks Calvin - for everything!!


Saturday, February 09, 2013

Fwd: Great Post: Realizing Your Potential As a Developer


After going through a week where I had to step in and review a developer's testing process before sending it to a tester because the tester kept on finding easy bugs, this post rejuvenated me.

You Know You're Failing to Realize Your Potential as a developer when you:

  • Don't Want To Learn
  • Don't Want To Commit
  • Don't Want To Understand
  • Don't Want To Code (Just analyze)
  • Don't Want To Ask 
  • Don't Want To Show
  • Don't Want To Read



Saturday, December 29, 2012

Judging Code

Sam Stephenson of 37 Signals wrote this post on December 13th, 2012 - You Are Not Your Code.

I didn't realize he was one of the authors of the Prototype framework or even that he worked at 37 signals (until the bottom of the post). The other point I wanted to make is that I don't think this is specific to "open-source" work either.

"Developers working together to build shared infrastructure: it’s the fundamental tenet of open-source software. Any motivated programmer with an idea and the ability to implement it can solve a common problem, share the solution with the world, and reap the rewards of future improvements by peer review."

It's not just open-source software - it's ANY software. Every product or project you work on typically involves working together, even if it's by simply pitting your own crazy ideas against each other. You solve a problem and then you get reviewed, whether it be by peers, superiors or, far worse, the purchasing public.

When building software, you make trade-offs. On a recent project, we had to move the prototype quickly into production because it was clear that it would take too much time to recreate it from scratch. For another client, work that was supposed to last for four years (while waiting for a new product) has lasted over fifteen. When you look back at your old code, you likely cringe at some decisions were made - but that was then, this is now.

I can feel his pain though  -
"The reality is that Prototype helped lots of people despite its flawed foundation. But its time had come and gone, and I eventually realized it was time to move on.
It was hard not to take Prototype’s failure personally. Critical blog posts felt like a full assault on my values. And seeing friends use other libraries made me feel like my work was a waste."

It's a great read - and as he notes :

"... you are not your code. A critique of your project is not tantamount to a personal attack.... It is simply the result of a regenerative process, driven by an unending desire to improve the status quo."

As I noted above, I don't believe this is exclusive to the open-source world or software. Sure, companies are judged based on their products; but more importantly, they are based on their service to customers. But as individual developers, your code should always be open to criticism, by yourself or by others.

What is an example of a perfect line of code? Is it:

print "Hello World"

(why are you using double quotes, why do I need to say Print, why is it in proper case?)

Hey, Kevin Ragsdale has a series of posts on how ugly FoxPro is --- I would expect that none of the Fox team takes offense to his posts. They created a canvas - what you do with it is your business.

Ayn Rand once said "Judge and prepare to be judged"

It's how you react to that judgement or criticism that shows your character.

Thanks Sam - great post.