PDFXporter + Polymorphical Project Diary :: Rapid Project Development :: Day #13

Read the Disclaimers and Warranties and download the Pre-Alpha now

Day #13 – Billable Hours #1 -6

Application Prototype in a Single Day !

This is the first big real-world test for the concepts published in this article series. Someone needed a complete Application rather quickly and since this is something near and dear to my own heart I chose to step-up and provide the prototype in just about 6 hours or effort.

Polymorphical is born !

By using the exact same code model from the PDFXporter Project I was able to build-out a completely functional Prototype for Polymorphical in just 6 hours of work.

Requirements:

These are the only two Requirements, there are no others.

  • Scan a bunch of JavaScript files and determine the Class Hierarchy for all these JavaScript files such that a Tree can be displayed.
  • Cache the Class Hierarchy based on the timestamps of all the files that describe nodes in the Class Hierarchy so that users can display the information quickly without having to scan each time.

Why use the PDFXporter Project as the template for Polymorphical ?

The answer is simple.

Because I can !

Because the new Application should inherit 100% of the functionality of the former !

Because doing this is just cool !

And because the guy for whom this work is being done might just be a little bit impressed and that might work wonders for my career.

Day #13 – Billable Hours #6 -8

Rework the Model so both Projects share more code !

Now that there are two different Projects sharing the underlying Framework the time has come to allow many more Projects to be spawned from this Framework by building a common upper-level Framework; the lower-level or Core code is already 100% reusable.

Project Recap so far…

During the previous 12 days of development the following has been accomplished by one single individual contributor:

  • Reusable Cloud-based versioned API has been created, tested, validated and placed online with live code.
    • The Cloud-based API can easily be reused for ANY project or product that requires License Management.
      • If one Product can be produced then ANY number of Products can also be produced with minimal effort.
        • Two (2) different Projects have been built so far using very little time and effort.
          • ALL Projects that stem from the original share the very same Cloud-based Back-end now this saves time and money like there is no tomorrow.
    • The License Management System can be easily extended to require Pay-Per-Use or Pay-Per-User or any other viable model.
      • The Payment processing System could be any usable provider such as PayPal or Google Checkout.
      • License Management System also supports Freeware.
      • License Management System does not use OpenID nor does it require Users to have Google Accounts.
        • OpenID or Google Account Authentication could be used going forward as options.
        • FaceBook Authentication is also an option going forward.
    • Terms and Conditions have been installed in the product.
    • Auto-Updater has been coded but needs to be tested using a real-world scenario.
    • Badge Installer for the Personal Version has been completed and is online.
    • Version 0.1.1.0 has been deployed and is online.
  • Reusable Adobe AIR 2.5 Framework has been created, tested, validated and placed online with live code.
    • Adobe AIR 2.5 also means there could easily be an Android App using much of the same code as is used by the Desktop App.
    • Native Installer means Native Process Support is automatic – this allows the Desktop versions to be augmented by some rather powerful client-side code, should this become a requirement.
    • Adobe AIR 2.5 also means the Desktop version could run in Windows, Mac and Linux however for now the pre-Alpha version is Windows only.

PDFXporter Project Diary :: Rapid Project Start-Up :: Day #1

Advertisements

PDFXporter Project Diary :: Rapid Project Development :: Day #12

Read the Disclaimers and Warranties and download the Pre-Alpha now

Day #12 – Billable Hours #1 -4

Reworking the Security Model a bit at this time

Making sure the Security Model is a bit more secure… And now the Security Model is more secure.

The Goal now… Export PDF Bank Statement as .XLS or .CSV

Now I can focus on exporting the information (ASCII Text) from a PDF Bank Statement as Data in the form of .XLS or .CSV.

Day #12 – Billable Hours #5 -8

Beginning to get data from Bank Statement PDFs

The process has begun… getting data… building the GUI… fleshing-out the API… building the Cloud Support.

Google App Engine requires API Requests to complete within 10 secs.

Much processing is required to handle the conversion of ASCII Text to Data for each page of the Bank Statement PDF. The process must be carved-up into a pipelined process for Personal Version Users who are running the App from the Cloud. It may be necessary to process the ASCII Text into Data via the Client rather than the server however for now the process is being run in the Cloud since code can be reused from a previous effort for this purpose; and let’s face it, Python is a much better language for processing text into data than AS3.

Project Recap so far…

During the previous 12 days of development the following has been accomplished by one single individual contributor:

  • Reusable Cloud-based versioned API has been created, tested, validated and placed online with live code.
    • The Cloud-based API can easily be reused for ANY project or product that requires License Management.
      • If one Product can be produced then ANY number of Products can also be produced with minimal effort.
    • The License Management System can be easily extended to require Pay-Per-Use or Pay-Per-User or any other viable model.
      • The Payment processing System could be any usable provider such as PayPal or Google Checkout.
      • License Management System also supports Freeware.
      • License Management System does not use OpenID nor does it require Users to have Google Accounts.
        • OpenID or Google Account Authentication could be used going forward as options.
        • FaceBook Authentication is also an option going forward.
    • Terms and Conditions have been installed in the product.
    • Auto-Updater has been coded but needs to be tested using a real-world scenario.
    • Badge Installer for the Personal Version has been completed and is online.
    • Version 0.1.1.0 has been deployed and is online.
  • Reusable Adobe AIR 2.5 Framework has been created, tested, validated and placed online with live code.
    • Adobe AIR 2.5 also means there could easily be an Android App using much of the same code as is used by the Desktop App.
    • Native Installer means Native Process Support is automatic – this allows the Desktop versions to be augmented by some rather powerful client-side code, should this become a requirement.
    • Adobe AIR 2.5 also means the Desktop version could run in Windows, Mac and Linux however for now the pre-Alpha version is Windows only.

PDFXporter + Polymorphical Project Diary :: Rapid Project Development Day 13


Coder or Software Engineer, which are you ?

Coders are like the proverbial monkey that bangs-out works of Shakespeare if given enough time !

Hint: You can infer a Software Engineer is the opposite of a typical coder…

Coders know how to bang-out code but they very often do NOT know nor do they care about the underlying “science” as-in “Computer Science”.

Coders will use really bad coding practices all the while thinking they are writing great code.

Coders will do things like issue a return statement from within a try…catch block without so much as ever thinking, if they ever think at-all, they should NOT be using such a stupid coding construct because it just violates the hell out of Top-Down Coding Styles they should really be using instead.

Coders will notice, or say they notice, their exception handlers are going to fire even when there is no real exception just because they issued a return from within a try…catch block without so much as thinking, if they ever do think, their exception handlers should only fire when there is a valid exception and just issuing a return should NOT be flagged as being an exception at-all.

Coders will use MVC (Model View Controller) for the sake of MVC and not so much for any other reason.

Coders love Ruby on Rails because it is “fun” to code !

Coders love Java because it is “Enterprise”.

Coders love PHP because it is everywhere.

Software Engineers know the “science” and they use it !

Software Engineers design software because they know the science.

Really great Software Engineers will also understand too much science is just silly.

It’s one thing to know how to recognize certain programming problems as being linear or exponential or whatever – it is another thing to know, from experience, how to optimize that algorithm to make it smoke regardless of what the computer science professors had been telling you while you were in school.

Top-Down Structured Programming

Enter at the top and exit at the bottom. Simple enough. So why do so many coders fail to understand when and why to write code that looks like it is top-down and structured ?!?

The Top-Down Structured approach much like Object-Oriented Design have largely fallen into disrepute but not because there is anything wrong with using these techniques – more because so many coders out there fail to see the value in using them.

Top-Down Structured Programs are easier to read than the others and easier to maintain.

Software Engineers will use the best technology, whatever it happens to be, for the solution rather than whatever seems to be the favorite.

Favorites are okay when we are talking about ice cream or cake but not for technology choices and surely NOT when working on a professional level.

The best technology choices will be those that produce better results using fewer resources with the best performance for the lowest cost.

Impress me with your technology choices !

If Ruby on Rails was really all that great as a technology choice then nobody should ever see that big blue whale while using Twitter but sadly this is not the case.

What it is about a web server that requires a big blue whale to appear, ever ?!? Is it not possible to build a web server farm (cloud or whatever) that can scale as the number of users increases or what ?!?

Surely it must be possible to build and deploy web servers so that even when millions of users suddenly appear the underlying technology stack can efficiently handle the surge or requests… unless you are using Ruby on Rails or PHP or Java and then since all these languages are really just single-threaded and cannot scale with the traffic there will be problems like those that require that big blue whale to appear being supported by little flapping birds.

Impress me with your programming style !

Ask me intelligent well thought-out questions while we are talking so I can understand you have done some serious thinking about software engineering rather than not…

I will never be impressed with those who just have to use Ruby on Rails as a technology choice when processing mountains of data… because ?!? There are so many better choices one could have used.

But… if you do choose to use Ruby on Rails for whatever then can you at-least be successful at accomplishing your goals !!! Please !

Whenever I am faced with those who have failed to impress with their technology choices I tend to go back to the thought process that seeks to find the best technology choices that fill the needs in a more efficient manner.

Coders versus Software Engineers

Coders make stupid choices !

Engineers make smart choices !

Coders choose favorite technologies !

Engineers choose the best most efficient technologies !

Coders build servers that max-out at 1 million hits per day.

Engineers build servers that max-out at some unbelievable number of hits per day nobody has ever heard of before.

Coders choose Ruby on Rails and then hope for the day when some Ruby version can outperform JavaScript !

Engineers choose Python because it smokes and they know how to make it smoke faster.

Coders choose to convert PHP into C++ without ever knowing Python already does this. (Python does not convert PHP to C++ but when properly used Python achieves performance as close to that of C++ as can be achieved without having to slog through the chore of actually coding C++)

Coders choose Java not because it is the most efficient technology choice but because someone told them it was “Enterprise” and that means something to them because you cannot go wrong with anything that claims to be “Enterprise”.

Engineers realize Java is single-threaded and single-threaded means you cannot leverage the server to the extent you may wish to – same reason PHP and Ruby are bad choices – all are single-threaded.

Be an Engineer NOT a Coder !

PDFXporter Project Diary :: Rapid Project Development :: Day #11

Read the Disclaimers and Warranties and download the Pre-Alpha now:

Day #11 – Billable Hours #1 -4

The Goal now… Recode that lame Auto-Updater Code from Yesterday

Not going to go back over why this is being done but rest assured this code module will be cool once I am done with it. Honestly, I think the original author would have done what I am about to do had he thought about it but alas he probably doesn’t have the required experience level to allow him to go where I will take this code module.

Auto-Updater is no longer lame !

As it turns out the Auto-Updater code just needed a bit of server-side magic to complete that circuit. Still have to test this part of the product however for being in Day #11 there is no need to get all axel-wrapped over whether or not all the code is perfect since the ability to perform Auto-Updates will come out in the wash sooner or later and surely before the product has been releases as a Beta version.

Needless to say, I do not allow code into my own products unless I know it will work and has been thoroughly tested – again I do not even bother to call this “Unit Testing” because this is just a fact of life – code must be tested and so it shall be.

Day #11 – Billable Hours #5 -8

Badge Installer / Enterprise Edition / Trialware-Freeware-Personal Versions

Then Badge Installer for those who just don’t want to download the installer – Badge Installers know how to install the product from the web – click on an icon or something then watch the installation happen, this sort of thing. Obviously those who install using the Native Installer will have a more powerful Application due to the Native Process support that goes along with the Native Installer; those who install from the Badge Installer will be getting into the Trialware Version where they can try-it-before-buying-it sort of thing. The Native Installer Version will be the Enterprise Edition and the Badge Installer Version will be the Trialware/Freeware/Personal Version.

Downloads are too big !

Yup, I have produced so much code during the first 11 days… well Google App Engine has limits and one of them is the file size so now I have to relocate the downloads to another server farm – also Google App Engine has bandwidth limits but never fear all this takes is a bit of time. Google App Engine remains a free resource for me and not only because I know how to use that TCP/IP thing… but I do !

Project Recap so far…

During the previous 11 days of development the following has been accomplished by one single individual contributor:

  • Reusable Cloud-based versioned API has been created, tested, validated and placed online with live code.
    • The Cloud-based API can easily be reused for ANY project or product that requires License Management.
      • If one Product can be produced then ANY number of Products can also be produced with minimal effort.
    • The License Management System can be easily extended to require Pay-Per-Use or Pay-Per-User or any other viable model.
      • The Payment processing System could be any usable provider such as PayPal or Google Checkout.
      • License Management System also supports Freeware.
      • License Management System does not use OpenID nor does it require Users to have Google Accounts.
        • OpenID or Google Account Authentication could be used going forward as options.
        • FaceBook Authentication is also an option going forward.
    • Terms and Conditions have been installed in the product.
    • Auto-Updater has been coded but needs to be tested using a real-world scenario.
    • Badge Installer for the Personal Version has been completed and is online.
    • Version 0.1.1.0 has been deployed and is online.
  • Reusable Adobe AIR 2.5 Framework has been created, tested, validated and placed online with live code.
    • Adobe AIR 2.5 also means there could easily be an Android App using much of the same code as is used by the Desktop App.
    • Native Installer means Native Process Support is automatic – this allows the Desktop versions to be augmented by some rather powerful client-side code, should this become a requirement.
    • Adobe AIR 2.5 also means the Desktop version could run in Windows, Mac and Linux however for now the pre-Alpha version is Windows only.

PDFXporter Project Diary :: Rapid Project Development :: Day #12


PDFXporter Project Diary :: Rapid Project Development :: Day #10

Read the Disclaimers and Warranties and download the Pre-Alpha now:

Day #10 – Billable Hours #1 -5

The Goal now… Terms and Conditions of Service and Automatic Updates

Now the goal is to craft some Terms and Conditions for use and all that legal stuff nobody likes to think about except Lawyers and those who like to cover their buns.

Users must now read and respond to the Terms and Conditions before they can upload Bank Statement PDF Documents for processing.

Day #10 – Billable Hours #6 -8

Automatic Updates

Then Automatic Updates… this is why people love using Adobe AIR Apps – they keep themselves updated.

The Auto-Updater code I found doesn’t work very well so I am recoding it using my own specifications which as you may know from reading my blog posts, it has to work and when it don’t work I make it work. I am not a fan of XML at-all because when I am paying for the bandwidth JSON works better, when you pay for the bandwidth you can use XML, no worries. Also the code the author of the Auto-Updater module I found used a rather lame technique for fetching XML from a URL and let’s face it I have much better code that just works better – duh ! But seriously folks, what’s the point of using code that only works sometimes when you can deploy code that works all the time. By the time I am done with this Auto-Updater Code rewrite I will have a much more robust system for handling Auto-Updates for my Native Installer Version which should also work for the Bade Installer Version as well but I will have to see how this all works.

Badge Installer / Enterprise Edition / Trialware-Freeware Versions

Then Badge Installer for those who just don’t want to download the installer – Badge Installers know how to install the product from the web – click on an icon or something then watch the installation happen, this sort of thing. Obviously those who install using the Native Installer will have a more powerful Application due to the Native Process support that goes along with the Native Installer; those who install from the Badge Installer will be getting into the Trialware Version where they can try-it-before-buying-it sort of thing. The Native Installer Version will be the Enterprise Edition and the Badge Installer Version will be the Trialware/Freeware Version.

Project Recap so far…

During the previous 10 days of development the following has been accomplished by one single individual contributor:

  • Reusable Cloud-based versioned API has been created, tested, validated and placed online with live code.
    • The Cloud-based API can easily be reused for ANY project or product that requires License Management.
      • If one Product can be produced then ANY number of Products can also be produced with minimal effort.
    • The License Management System can be easily extended to require Pay-Per-Use or Pay-Per-User or any other viable model.
      • The Payment processing System could be any usable provider such as PayPal or Google Checkout.
      • License Management System also supports Freeware.
      • License Management System does not use OpenID nor does it require Users to have Google Accounts.
        • OpenID or Google Account Authentication could be used going forward as options.
        • FaceBook Authentication is also an option going forward.
    • Terms and Conditions have been installed in the product.
    • Initial version of the Auto-Updater has been installed but must be recoded due to lameness.
  • Reusable Adobe AIR 2.5 Framework has been created, tested, validated and placed online with live code.
    • Adobe AIR 2.5 also means there could easily be an Android App using much of the same code as is used by the Desktop App.
    • Native Installer means Native Process Support is automatic – this allows the Desktop versions to be augmented by some rather powerful client-side code, should this become a requirement.
    • Adobe AIR 2.5 also means the Desktop version could run in Windows, Mac and Linux however for now the pre-Alpha version is Windows only.

PDFXporter Project Diary :: Rapid Project Development :: Day #11


PDFXporter Project Diary :: Rapid Project Development :: Day #8

Read the Disclaimers and Warranties and download the Pre-Alpha now:

Day #8 – Billable Hour #1

License Management System is Done and Functional for now…

License Management System is now online and functional in the Cloud for Production and development is being done using the Cloud as part of the validation process.

Users are able to Register, Get Activation Code via Email, Resend Activation Code and Login. This is good enough for now and development can proceed to head into the Login/Logout States to allow users to Login to Use the Product and then be logged-out once the product is halted and the user returns to the Desktop. There is no need to halt development to perform a complete validation of all the API functions right now however now that Users can Login the Logout function is required and then the other API functions can be validated before moving to the rest of the Product GUI.

Day #8 – Billable Hour #2

Working on the Login/Logout State Transitions…

Also working on handling Full Screen versus Windowed modes – Users will begin Full Screen and remain Full Screen until they switch to Windowed – both states are persisted locally in a Shared Object. Same thing goes for window size issues – persisted locally..

Thinking about doing some parallel development, just because I can…

Sure PDFXporter Development has been going on for sometime now, working on the core of the system but… What if I wanted to do some parallel development to work on some features I may wish to work into a future product – like the following:

  • XMPP Server for Desktop Client – useful for Peer-2-Peer and Social Networking.
  • XMPP Client for Desktop Client – useful for Peer-2-Peer and Social Networking.

Peer 2 Peer Product Ideas

Secure Peer 2 Peer File Transfers such as those being done using Torrent would make for a slick product and not only because this would be true Peer 2 Peer using a secure encrypted pipe rather than that Torrent crap people can sniff to see what you are doing. All this takes is some XMPP Client/Server Magic that only requires both the Client and Server to be running on the Desktop via Adobe AIR and AS3 – not a big deal. Google App Engine provides for some XMPP functionality also to help make this all seamless.

Social Networking Ideas

Once a User can login via the Cloud all Users can be made aware of all other users and those Users can begin to get connected to each other using XMPP Messaging.

Why work on just One Product when Many Products can be Developed in Parallel at the Same Time ?!?

Flash Builder 4 makes this very easy – one single body of source code can be easily shared between many AIR 2.5 Apps at the same time all in the same “Project” – nice, huh ?

When I am working on one product, like this, I like to think about developing as many uses for my code as possible – for as many markets as possible and why not ?!?

Day #8 – Billable Hour #3

Added a MenuBar…

What self-respecting Desktop App doesn’t have some kind of menu bar ? Just added one and debugged it to make sure it works – you can call this Unit Testing, if it makes you feel better about things. I just call this “development” which is to say, if making sure the code works is known as “Unit Testing” then let’s call it that but I don’t even think about breathing air or pumping blood just because I am alive therefore I don’t give any thought as to whether or not I will make sure my code works because doing that is as sure as breathing air and pumping blood – if I code I test, just that simple.

Day #8 – Billable Hour #4

Added a yet another Product to the Mix (Parallel Development Rules)…

So lately I have been uploading a ton of unique content to YouTube in the form of video game-play sessions specially tuned to young males between the ages of 12 and 39. This of course means I will have content for yet another product in the form of an App that knows how to display YouTube videos directly from My Channel. This also means because I am using Adobe AIR 2.5 I can quickly and easily produce an Android App that uses much of the same code I am using for my other products that also use Adobe AIR 2.5, you gotta love code reuse. Not only can I produce products I can ship to my growing Sales Channels for Desktop Apps but I can also ship Android Apps using very little effort.

Day #8 – Billable Hours #5-8

Need code for a File Uploader in Flex 3 for a Flash Builder 4 App ? Got one from 2009 !

Code Reuse to the rescue one more time. This time I needed a File Uploader widget so I grabbed one off the shelf from sometime in 2009 when I previously coded this sort of thing. Bingo, code is reused. Saved some hours on this one…

Now working on the code that uploads PDF files to the Cloud where the PDF will be exported as Data and by Data I mean Data suitable for being used as real live Data, you know, the kind of Data one might be able to use as Data rather than Text.

What is Data versus What is Text ?

Data is something you can use to process things like Categorized Income and Expenses suitable for supporting your rather clever IRS Tax Deductions – you will still need to find all those receipts but when you can pull your categorized Income and Expense Data from your Bank Statement PDFs you will be saving a ton of time.

Data provides information you can process. Text is just text – you have to parse Text to make Text into Data. This is why PDFXporter is so valuable – you upload your Bank Statement PDFs and you get back real live Data in the form of .XLS or .CSV files, your choice.

Later versions of PDFXporter will provide charts and graphs as well as slick reports you can pull directly into your IRS Tax Filing in case you are ever audited.

Later versions of PDFXporter will provide IRS Audit Support Docs in the form of PDF Documents you can print locally on your own printer OR you will have the option of printing remotely for a small nominal fee.

PDF Upload is coded and functional

Phase I is completed – PDF files are being uploaded but not yet processed into data.

PDFXporter Project Diary :: Rapid Project Development :: Day #9


PDFXporter Project Diary :: Rapid Project Development :: Day #7

Read the Disclaimers and Warranties and download the Pre-Alpha now:

Day #7 – Billable Hours 1 – 8

Complete the License Management System is the Goal

License Management System is online in the Cloud for Production and on the Desktop for Development. The GUI has been updated to allow the API to be used for Development via a local server and in the Cloud for Production; both servers can be validated side-by-side.

Just to recap.

  • A complete License Management System with GUI has been completed during the first 7 days with working code running via localhost and the Google Cloud.
  • An initial GUI has been created with a slick animated company logo.
  • A reusable Adobe AIR Application Framework that supports Windows, Mac and Linux with full support for file names that are not case sensitive (Mac and Linux require case sensitive file names however Windows does not – Windows is an ideal Development Platform because Mac and Linux Apps can easily be made to mimic the behavior of files for Windows which is to say once this is done one can freely develop high-impact Adobe AIR Apps for Windows that just work once ported to the Mac and Linux OS without having to give any thought to how file names are being handled.)
  • This is a 7 Day Development process I will NEVER again have to repeat – this saves 7 days every time I reuse this Application Framework – this is a huge savings in time and money and this reduces time to market.
  • Just try to replicate this experience in your software development practice. I was not even spending most of my time working on this 1 project during the time this code was being written – I was maybe spending 20% to 50% of my time working on this project with the rest of my time being spent on other pursuits.

Now I have a reusable Framework for the Development and Deployment of Adobe AIR Applications that leverage the Google Cloud with License Management that will be hooked into a payment processing system to allow users to play with the Applications before paying to use them.

PDFXporter Project Diary :: Rapid Project Development :: Day #8



%d bloggers like this: