Wednesday, September 10, 2014

AppleSoft

I'm not TRYING to be "fanboy-flame bait" but what I saw yesterday was a typical "Do it this way, now do it this way and then we'll go back to this way" all over again.... a move similar to what Microsoft does to developers on an ongoing basis.

Remember the first iPhone? Smooth and curved, at least as far as it could be back then. I still pull out my 3G and can see the curves on it.

Then the 4 came out and "boxy" was all the rage. Everything should be "tight with corners"

Now iPhone 6.... smooth and curvy is back. Granted I don't have the actual device yet, but that's the message.

Guess that means the iPhone 8 will be back to boxy.

And honestly, Apple Watch is not worth "one more thing" --- especially when everyone knows it's going to be shown. "One more thing" would be something no one saw coming.  The device itself ? Very interesting and yes, definitely lots of potential but "one more thing" worthy? No. Maybe I'm just jaded.

One more "bad thing" is that the Apple Watch (which does look very cool) requires an iPhone. So now you can walk around with more Apple devices instead of just one. If you're going to change my life, make my load lighter, not heavier.

So much for real Continuity.

Thursday, August 21, 2014

WPF - Setting Up Themes

Forcing WPF to use a specific Windows theme | I Got Rhythm

At a client recently, we developed our WPF application under Windows 7, tested it under Windows XP and everything looked great. 
Then it was deployed.
As it turns out, one of the deployments was over a Citrix server that forced applications to run under Classic mode. 
Those of you who have worked with various operating systems over the years will know what I'm talking about. Classic mode isn't quite classic, unless you are one of the few who think playing bar pong on an 84" TV is superior to playing one of the more dimensional games. Or maybe one of the few who like to get up and change the TV channel rather than finding the remote. Or one of the .... (you get the idea)
While most things converted well, Tabs do not. In WPF, we have these beautiful tabs that look fresh but over in Classic mode, they have the look and feel of, well, Classic Windows 95 and VB 6 applications.
The application was demo'd to the client under Windows 7 but deployed under Windows Classic so all of a sudden, the user's experience went from "wow, that looks great" to "what kind of crap did you give me".
But all was not lost. I found this very old (2006) but super useful post about forcing WPF to use a theme. In the end, it was as simple as adding a forced reference to PresentationFramework.Aero in the solution and adding

  <ResourceDictionary.MergedDictionaries>

        <ResourceDictionary Source="/PresentationFramework.Aero;component/themes/Aero.NormalColor.xaml" />

    </ResourceDictionary.MergedDictionaries

to the Resource dictionary (or to the Application.xaml file).

Voila our tabs went from crap to zap!

To make the experience even more sweet, that post from 2006? The blog is still being updated today (a lot more posts than here recently as well). Well done, Aelij Arbel, well done and Thank you!

 

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!!