Know Java & Still don't want to learn ObjectiveC but want to make iOS apps?

Then you want to have a look at this:  https://code.google.com/p/j2objc/

This will not just magically port all of your code from Java into an iOS application - in terms of the UI anyway - however, the majority of your internal code is going to do exactly that.

Of particular note is the JUnit support which strikes me as extremely useful & civilized.

Kill Access With Fire

I want to be very careful how I phrase this.  We can't have any Redmond-funded lawyers circling around me like hungry sharks because my hyperbole is mistaken for meat swim-trunks.

So let's keep it personal - I Hate Microsoft Access^{TM (C) LMNOP}.

It is a blight on civilized companies everywhere.  By being included in the Office Bundle/Suite/Tollset [spelling intentional] MS-Access is available to entirely too many aspiring tech-savvy "business" people.

It happens slowly over time - first some good intentioned person needs to manage a lot of data.  By a lot we mean more than the spreadsheets that they would ordinarily (ab)use to store them.

And so they make a rudimentary table and load a lot of data into it.  This works so well that they start doing it all over the place.  Quickly however the relationships between the tables become convoluted.

This is where someone who truly understands database design should be brought in to fix things before proceeding.  This is never the case however and so slowly does a swamp start to grow that will need to be drained later.

I have worked on projects in the past where we have tried to leverage automation tools to convert the database structure of Access files to another format - for example Oracle APEX.

Another example of such a tool that I recently discovered would be : http://www.bullzip.com/products/a2m/info.php

But the problem of course is that there is so much inherent functionality^* in Access that it is neigh-impossible to capture it all in another tool on another platform.  Just the integrated ability to send email through Outlook alone represents a huge functional gap for any other system.

You would at first think that the sorts of things that would be made would be simple and thus easy to reverse engineer, but as it happens there is an inherent dogged spirit of innovation in the people who are using these tools and trying to get everything that they can out of them and thus Yes, people send email from Access and many other things like making forms with buttons to run import scripts, etc.

Moreover those people will live with such a solution for a very long time before being compelled to change.

The challenge for IT is that they must provide not only a new replacement toolset that can accommodate all of the preexisting functionality but also do so in an enterprise-scaled solution.

The problems are always that such a replacement is very expensive & almost always inflexible whereas Access is extremely cheap by comparison & can be modified on the fly.

The big problems of course with MS-Access are that it does not scale well nor is is compatible with anything else or even with itself across version numbers.

There are severe limitations to the amount of data that can be stored in a single file and also with the number of simultaneous users that can access the database simultaneously.

MS-Access is not even compatible with MS-SQL Server for direct import.  The syntax varies wildly  between the two.

So in short - MS-Access databases start off sweet but if you are successful then they will end in bitter tears.

_
^* - You might think "too much functionality is a problem?" But it is more of a question of the types of functionality since Enterprise databases do not generally include for example email functionality.

What is Microsoft Smoking to make their Cloud?

"With cloud, infrastructure homogeneity enables scale economies."

On What Planet does cloud = homogeneity ?  Maybe on Planet Microsoft, but for the rest of us who don't live is a 1950's comic book it just aint so.


[20140505: This is a retro-post that just never went live - likely because I never really got started, nevermind finishing it.  But why didn't I just post the above Tweet-like entry?  I don't have a Good Reason, so I just hit post now.  See how that works?] 

BYOD vs. CYOD vs. Buy Gear for your Employees

I have always been an early adopter.  While my tastes have become refined over the years & I don't actually buy every release of a tech line anymore - this is only because I am too busy using the hell out of said tool/toy/gadget.

 When I do go buy new gear - I buy on a generational scale.  I assume that I will use the thing long past the average curve & that it will see a heavy workload for the duration.

I buy the best version that I can get my hands on & if it comes with any free slots or expansion ports I try to fill them up when I buy it.  There's no sense paying for an expansion port that isn't doing anything for you & almost any system will perform better with more RAM, so why hold back?

That being said - you can expect me to use these tools of the trade to the greatest personal advantage.  That is what drives the purchasing decision in the first place.  "Cool" is only about how much power it gives me to easily do awesome things without wanting to break the thing out of frustration.

This is why the notion of BYOD worked perfectly for me.  Give me clearly defined rules like "no proprietary corporate data stored on the device" and I can work with that.  No outlook for my iPhone, I will just use the web-based interface.  Simple.  Everything is on my terms & kept reasonable.  I am free to go find the best tools for the job.

Choose-Your-Own-Device is quite another thing. The notion that there is a limited subset of devices out there & that your internal IT department has to research them & understand them before you are allowed to use them stifles innovation outright.  

It would apparently also set what I see as an unfair burden on the shoulders of employees who are willing to shell out for their own kit by forcing them to keep to a standard for which the company is not itself willing to pay.

The age-old policy of issuing devices to employees solves that issue.  If the company wants everything to work a certain way then they need to foot the bill for it.  This doesn't help with the innovation either but it offers some relief to the wallets of employees and limits the technological options to a manageable subset.

There is no one-size-fits-all policy for corporations, but the answers seems to directly come from those willing to shell out for the gear.  If you own it you control it and the law backs you up on that most of the time.

Google Too Pushy - Pushing me to Bing!?

I got a new computer at work.  I was setting it up and suddenly got hit with one of these:






Now I ask you plainly: which is more likely - that I am going to spend anything more than 20 minutes - never mind the next 3 hours - downloading software & trying to diagnose malware on my computer by following Google's suggestions - OR that I am just going to switch my browser to use Bing or anything else instead?

This sort of approach will cost them in the long run.

Pythonista

Having continued in my journey to try to migrate my mindset from that of a Java programmer to one that is Python-centric, I thought that it might be a Good Idea to get a hold of a Python environment for my iPad.

My expectations were very low.  For some reason I just had assumed that Python would get the same treatment as Java - which is to say that any real use would be curtailed, but maybe I could write some code here or there that I could upload to a computer to do something with.

I was shocked and amazed to find that not only does Python run, almost completely, but that it can be used to create GUI-driven iPad applications!

Enter Pythonista - the best $7 that I have spent in a long time.  Within the first day I was tracking multi-touch finger contacts, drawing graphics, using the camera API, performing image manipulation, and playing sound effects.

Mind you, while I am an accomplished Java and perl programmer - I am still a relative n00b to Python - so the idea that I had jumped ahead to performing GUI-based tasks was Very Encouraging.

I think I will stick with this for a while.  Next stop - How do I use Pythonista to drive a mobile connection to a web2py-based application?

Killer...

My deep-dive of Python and web2py has led me inexorably to a very nice learning resource: Killer-Web-Development.com

It is a nice walk-through of the web framework along with a plausible fiction that fills in the blanks as to why you might want to use it.

I am particularly fond of the idea of the "Pitch Application" as this is a concrete real-world example of exactly how these kind of development projects get off of the ground to begin with.

I am presently working my way through this and I find that it complements web2py in that it is thoughtful and done well.

Insanely Great - Yet Another Web Framework - LOLWUT?

If you are a software developer then the two most unwelcome words that you can hear after the C-word (no, not that one - 'Cyberspace'...what are you, Scottish?)  would be the words "Web Framework".

This is for the simple reason that there are too damned many of them.  About a decade ago the word "Framework" started to buzz and suddenly they were falling out of the sky like dead flies in a DDT cloud.  You couldn't pick up a magazine (remember when we had those?) without coming across at least a half-dozen of them.  Being as it was Universally-Agreed-that-Every-Piece-of-Software-Has-to-Be-a-Web-App there was a perceived need to make the chore of doing so far more simple.  Ironically, the complexity that many of them added eventually ended up doing exactly the opposite.

A lot of them were Frankenstein-like composites of components hastily slapped together without any regard for maintainability.  While the components themselves might have been Best Of Breed - the way that they were slapped together and pushed as a single package was so common and problem-laden that it constitutes an anti-pattern.

Sometimes you just have to start over from scratch.

Being new to web development with Python, it seemed prudent to find a framework.  Having reviewed everything that I could get my hands on, the winner was clearly Web2Py.

The reason for this is simple.  No, really, that is the reason.  It is simple.  It is simple to use, simple to understand, simple to implement and simple to customize.  Anything that can do that can vastly enhance productivity and IMHO that is brilliant.

Some frameworks adhere to a list of standards - usually somewhat begrudgingly - and treat them like a list of features on the side of a software box.  Web2Py has truly internalized them as design philosophies.  It has the benefits of having been designed as a feature-complete project prior to implementation.  As such is it very compact and at the same time extremely forgiving.

If you download the binary distribution you don't need a web server nor a database server nor even a text editor and yet you can be up & running and developing your own web application in under 10 minutes.  Once you are past the point where these rudimentary tools are useful it is a simple matter to introduce web server and database server tiers in a more robust fashion.  However, Web2Py takes the Web 2.0 paradigm to heart and even provides the ability to create and edit applications right in the web based administration application itself.

This means that learning how to use it is a history of building on successes, rather than clumsy mistakes constantly preventing you from getting something up and running.  This is a more encouraging way to learn how to program and that alone makes it better than the competing frameworks IMHO.

Where's the Ni!?

Just to pick nits here - one thing that I have noticed about Python is that the documentation specifically states that the language is named after Monty Python and not after snakes.  It goes on to say that Monty Python references are to be encouraged in the documentation and examples.  It is worth noting however that this almost never happens.

Sadly, being a fan of Monty Python, I am disappointed.

I am not sure why this is so, but I am considering making a module that would be replete with Family Guy references - just as an experiment - to see what kind of email responses it would get me...

Poking Python with a Stick

I have been crash-coursing Python recently and I wanted to share some thoughts about it as they occurred.  As I haven't bothered to post for a long time - since I tend to get bogged down in the news & politics and other such gloomy bullcrap - I'm going to try focusing on this aspect for a while & see if things don't brighten up just a touch...

I had a few false starts getting going with Python.  There are a few things that leave someone scratching their head.  For one thing - Don't use Python 3.x yet.  (unless you are reading this far in the future)

The reasoning for this is that the Core Python Developers themselves expected adoption of 3 to take 5 years.  However there were performance problems with the 3.0 release.  As a result it is best to reset the clock to the 3.1 release, which was in June of 2009.  Hence, the appropriate time to start considering Python 3.x for production use would be after June of 2014.

But again, why wait so long?  I mean this isn't a complete rewrite like Perl6 - why should it take so long?  The answers have to do with all of the code written for Python 2.x.  There were some fundamental changes that were made that largely deal with making unicode more consistent as well as calling internal functions.  These involved syntactic changes.  As a result - a lot of code has to be rewritten, retested, debugged & rereleased.

Next, there is the question of learning the basic syntax and the flavor of the language idioms.  For this I have been working my way through Google's PyQuick 2 day class, the videos for which are available on YouTube.  Things on YouTube seem to be somewhat fluid, so here is a link to the first of these videos, but you are probably better off just searching for "PyQuick".