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 !

Bad Coding Style regardless of the Language !

Every so often I am asked questions about how to write code, I do not even classify such conversations as those even remotely related to Software Engineering because “engineers” would not sit around talking about such sloppy work if one is talking on a professional level.

Bad Exception Handling Coding Patterns

Consider the following code:

Void foo() {

try {

// blah

// blah

// blah

return

} catch (e) {

//do something about the exception

}

}

The question was, “…will the exception block be executed when the return is executed…” ?

My response was NO !

The guy asking the questions said I was wrong.

My next response was an explanation about coding style and why his was just BAD.

Even if the correct response was that the exception block would be executed as a result of the return from within a try block one would have to write some extra code to ensure the exception block was not being executed as a result of the return because… *wait for it* what is the purpose of coding an exception block that is not being executed only when the exception is triggered by a real exception ?!?

Even if some language mechanics caused an exception block to be triggered when there was no real exception other than to return from within a try block doing this would only lead to code bloat if the goal was to ensure the exception code is only handling the real exception rather than some pseudo exception such as exiting from within a try block.

Additionally, if the exception was triggered before the return statement the return statement would not be executed and this is yet another reason to use a try…catch; a series of programming steps are to be done during which if an exception happens the rest of the steps should NOT be executed – this makes try…catch a very nice pattern one can use to ensure one’s code is behaving correctly and by correctly I mean in a logical manner one can rely upon such that the program will continue to operate even when exceptions happen.

Top-Down Programming

Also there is a concept known as top-down programming that states a function is entered at the top and exits at the bottom but it does not exit from the middle somewhere.

Top-Down Programming causes one’s code to be structured in such a manner so all who read this code can know for sure where the code enters and where it exits. Placing a return statement within a try…catch violates top-down programming by causing the function to exit somewhere other than at the bottom.

Code that adheres to Top-Down Programming will have exactly one entrance and one exit and only one of each. Just because one can write a return statement does not mean one should use more of one of them per function !

Return is just another way to spell GOTO !

Return or system.exit() statements are just another way to spell “GOTO” and they should be used as sparingly as possible.

What’s the Point ?

The reason we want to write good code rather than bad code is because we want those who read our code to know what the code is doing rather than the other thing that makes people get out their debuggers just to see what the code is doing.

The guy who loved his own bad coding practices and then got embarrassed as the thought that he was out in left field is the same guy who should get his act together and learn something about Top-Down Structured Programming in addition to how to write code everyone else in the room wants to read.

Also just because someone is paying you money to write code does not automatically mean all the code you may be writing is on a professional level especially when you are using BAD coding styles.

What makes one’s code BAD ?

Show your code to a bunch of people and get their reactions, the ones who feel the code is BAD are the ones who know BAD code when they see it – the rest are probably your friends or coworkers.

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


This is why I love PHP – NOT !!!

A critical vulnerability in the PHP engine has just been identified. This exploit is significant because most PHP applications on impacted systems are remotely exploitable to a very simple denial of service attack. Zend has released a security hotfix to address this vulnerability (see below).

Due to the way the PHP runtime handles internal conversion of floating point numbers, it is possible for a remote attacker to bring down a web application simply by adding a specific parameter to a query string in their web browser (click here for more information).

This vulnerability is present on all versions of PHP including PHP 4.x and 5.x, on all Intel-based 32-bit PHP builds.

Platform Vulnerability
Windows YES
Linux (using 32-bit PHP build) YES
Linux (using 64-bit PHP build) NO
Mac OS NO
IBM i NO

Zend Server and Zend Server CE users should immediately apply the security hotfix.

Hotfixes for Zend Core and Zend Server CE tarball installer are currently being finalized and will be made available soon.

Happy PHP’ing,
Zend – The PHP Company

%d bloggers like this: