GreekBible V1

Announcing the release of Greek Bible (Version 1):

Links

• Greek Bible App
• GitHub Source Code

Screenshots

Summary

Greek Bible displays the Greek New Testament with color coded morphology.
The color cording allows the reader to quickly see associated words in the greek text.

Features

• Read the Greek of any New Testament Book from the SBL Greek New Testament
• View details for each word:
  • View the Lemma (the root word)
  • View the Part of Speech
  • View the Morphology
• View the color coding for the Part of Speech and Morpology to quickly see associated words

MorphGNT

The MorphGNT includes a parsed morphological tagging of the SBL Greek New Testament. This work was created by James Tauber as part of his doctorite in linguistics.
More information about MorphGNT is found at: http://morphgnt.org

The SBL Greek New Testament

With the work of textual criticism far from complete, there is a continual need for fresh research and analysis. The SBLGNT, edited by Michael W. Holmes, utilizes a wide range of printed editions, all the major critical apparatuses, and the latest technical resources and manuscript discoveries to establish the text.
The result is a critically edited text that differs from the Nestle-Aland/United Bible Societies text in more than 540 variation units.
More information about the SBL Greek New Testament is found at: http://sblgnt.com

License

Attribution

• MorphGNT
  • MorphGNT.org
• SBL Greek New Testament
  • Copyright 2010 by the Society of Biblical Literature and Logos Bible Software
  • SBL Greek New Testament: http://sblgnt.com
  • Society of Biblical Literature: http://www.sbl-site.org
  • Logos Bible Software: http://www.logos.com

---

Developer Notes

Overview

The project was a great success for my first 5HourApp. Although, it took about 8 hours plus some extra time researching tools and setting up the environment.
I was able to rewrite the entire GreekBible. I only used a few pieces of logic from the oldGreekBible. It was unneccesary to reuse code because the frameworks I used actually made the code very simple to write from scratch.
Bottom Line: I was able to write a $5,000 web app that runs everywhere in about 8 hours. That's not bad!

5-Hour App

This proves that the 5HourApp concept is valid. I can actually create a fully functioning app to release in around 5 hours. The important part is to trim features and identify the most important user features to implement.

Feature Oriented Software Development

I feature organized my code files. This enabled me to focus on one feature at a time. It also allowed me to have a good separation of concerns between user features and the underlying system features that they need to function.
I identified two possible ways to divide a ViewModel across multiple files. In this project I used a mainViewState with a sub object for each feature.
An alternative would be to use typescript interfaces and a static object that is gradually implemented.

KnockoutJS

KnockoutJS is great! This was my first time to use it and it was a pleasure. I highly recommend it! I will be using it as my UI framework of choice.

jQueryMobile

jQueryMobile worked fine with all the defaults in place. However, one bug cost me about an hour because the generated jQueryMobile UI did not match the native UI behind it.
Next time something is not changing, inspect the DOM and see if there is a lone SPAN tag that doesn't match the actual $(element).val() or $(element).text(). Ensure that the proper refresh call is being made for jQueryMobile, which is different for each element type.
I created a refreshJQM Knockout binding to deal with this. I will expand it to automatically call the proper refresh code according to the bound element type.

File Structure

• Notes
  • Developer Notes
    • Required Tools
    • Setup
    • Interesting Techniques
  • Release Notes
    • Summary
    • Feature Descriptions
    • Version Changes
  • ScreenShots
• Scripts
  • js
    • Javascript Source Files (Not Generated)
    • External: Code from outside sources and libraries
  • ts
    • TypeScript
    • *.ts files: TypeScript Source Code
    • *.js files: Generated Javascript
    • External: Code from outside sources and libraries
    • Core: Definitions for core types
    • System: Features that are invisible to the user, but provide functionality for the User Features
    • User: Features which represent the user tasks and concerns
• Styles
  • css
    • CSS Source Files (not generated)
  • sass
    • Sass Files created using Compass
    • *.scss - Sassy CSS source
    • *.css - Generated CSS

Environment & Project Setup (Pre-Project)

Tools

• Visual Studio Express 2012 - Web
• Git Extensions for Windows
• TypeScript for VS
  • To Enable Compile on Save:
    • Tools/Options
    • > Text Editor/TypeScript/Project/General
    • > Automatically Compile...
  • TODO: Create a bat file to produce one js file for release (Indivudual files is good during Testing)
• NuGet Package Manager - VS Extension
• FAIL: Chutzpah Console (Extensions not Enabled for VS Express)
  • Download Console and unzipped to my Tools Folder
  • Created a bat file to run all the tests in the ts directory
    • chutzpah.console.exe ../WebSite/Scripts/ts /testMode TypeScript /openInBrowser
  • FAIL: This takes a long time to run and it failed to run a valid test. Testing in browser with a qunit tag enables debugging in browser and is fast.

Libraries

• jQuery Mobile
  • Copied Code from Demo to get started
    • jQuery.js
    • jQueryMobile.js
    • Default Theme Css
    • Images
  • TypeScript Definitions
    • NuGet PM> Install-Package jquery.TypeScript.DefinitelyTyped
    • FAILED: NuGet PM> Install-Package jquerymobile.TypeScript.DefinitelyTyped
    • NuGet PM> Install-Package jquerymobile.TypeScript.DefinitelyTyped -Version 0.1.2
• QUnit
  
  • QUnit JS & CSS
  • TypeScript Definitions
    • NuGet PM> Install-Package qunit.TypeScript.DefinitelyTyped
• KnockoutJS
  
  • knockout JS
  • TypeScript Definitions
    • NuGet PM> Install-Package knockout.TypeScript.DefinitelyTyped
• LinqJS
  
  • linq JS
  • TypeScript Definitions
    • NuGet PM> Install-Package linq.TypeScript.DefinitelyTyped

Future

• QUnit Pavlov Plugin - BDD
  • This looks like a good plugin to enable Behavior Driven Design language for QUnit tests
  • Would Require a TypeScript Definition File to be created

Bugs

• BUG: jQueryMobile was not updating the visible part of a select element (the native element was being updated, but the span on top was remaining an old value)
  • FIX: ($(element)).selectmenu('refresh');
• FAIL: Chutzpah Console caused wasted time and is unneccessary

---

Work Hours

Hour 1

• Created the structure for the DisplayGreekText feature
• Problems:
  • Running the qunit test for loading the sample text fails using Chutzpah

Hour 2

• Parsed the data from a chapter of text
  • Used oldGreekBible's parsing code as a starting place
• Passing Tests

Hour 3

• Displayed the passage text on screen with the details
  • Used oldGreekBible's formatting of the details

Hour 4

• Started to implement ChoosePassage
• Problems:
  • TypeScript does not support Partial classes, so had to pause to think about how to implement that
  • Slow Today
  • Not finished implementing ChoosePassage

Hour 5

• Divided Data into Chapters
• Binding Book and Chapter values to UI
• Triggering Reload on Book/Chapter change
• Started: Debugging UI binding
• Started: LoadPassage

Hour 6

• BUG: Chapter Select was not updating
  • FIX (1 hour): Finally discovered it was jQueryMobile not refreshing the UI

Hour 7

• Display Color Coding
• Finished Up Tasks
• Removed Unprintable Characters
• Removed QUnit results

Hour 8

Goals:

• [X] Display Verse Numbers
• [X] Create Release Branch
• [X] Write Blog
• [X] Publish
• [X] Publish Blog

Feature-Oriented Software Development and Feature-Organized Code

Software development is all about the apps. If you don’t have a user interface, then your software is pointless. There must be a way for somebody to work with your software to accomplish what they want to do. These are the features: what your app can actually do. Really, an app is nothing more than a collection of features. The best apps have few features that are closely related and are exceptional in quality.

Therefore, software development should focus on developing features.

All too often, we developers focus on the code, “Look how cool that code is.” Users don’t care. They want a cool feature that works – that is all. They don’t care about your hard work. If you don’t give them exceptional features, they will trash your app (1-star) and nobody will ever touch it again.

We must focus on the features. We must make exceptional features that shine. That is the entire purpose of software development. In fact, maybe we should just drop that term and call ourselves “feature developers”. Software is pointless unless it contributes towards exceptional features.

Background

We developers are overly focused on our code. Look at the OOP (Object Oriented Programming) paradigm for example. It’s main concern is how you design your class hierarchy.

That has little to do with a feature. So we have Use Cases where we try to figure out every possible way an object might be used. That is getting closer to the features, but it is putting the developer’s concern (class design) ahead of the user’s concern (features).

OOP solves many problems, but it also introduces a way of thinking that produces unnecessary complexity. A developer has the impression that he must design perfectly defined types that can handle all possible scenarios before programming can begin.This results in the common tendency of unexperienced programmers of trying to solve “world hunger” with every project. Many times he doesn’t even remember what feature he is trying to implement.

However, even a developer with an idea of the desired features can face a complex project. At the beginning of a project, each class is well defined and exists in a small easy to read and understand file. However, each new feature introduces changes that can span multiple class files. Over time, these files grow bloated with unrelated code. Even more, as multiple developers modify those files for their own needs, they can contain multiple styles and design patterns that make the code for that class very difficult to understand. Feature dependencies can be strung throughout the code base. “You can’t change that because it will break this. Oh and users have become used to that bug so don’t fix it.”

The entire project becomes a dark and dangerous place where you might violate some unwritten law by changing something you weren’t supposed to change. Then, you make yourself an enemy of the whole team who has to waste hours trying to trace down all the unexpected bugs caused by your change. As stress builds, the team becomes more concerned with who to blame rather than developing good software together. Obviously, this does not contribute to a positive development team.

My observation is that the end result of traditional OOP is an exponential growth in the cost of adding each new feature to a project.

Software development should not be object-oriented. In fact it should not be oriented to anything to do with the code itself. Software development should be feature-oriented. Developers should always have in mind what feature they are contributing towards.

With the big picture of the target feature in mind, then a developer can use whatever code most simply implements that target feature.

(Keep in mind that there are “system features” which provide the foundation on which the “user features” are built.)

Thinking Differently about Code Organization

My experience with C# and it’s changes over the years eventually led me to a different way of organizing my code.

The introduction of partial classes to C# initially allowed a simple way to separate designer generated code from human code.

Then later, extension methods allowed me, being used to strictly defined traditional OOP types, to start thinking about types that could be extended at a later time.

Then, my exposure to javascript with its purely dynamic types made me realize even more possibilities about objects and type definitions and how they could be extended even at runtime as needed.

In the end, these experiences led me to organize my code differently than I had been taught or had ever done before. In my latest project, I unintentionally organized my code in what I will call feature-organized.

Towards Feature-Organized Code

As I was working on this project, I wanted a clean working space so that I could focus solely on a single feature at a time. Therefore, each time I started implementing a new feature, I added a new file to the project and kept all the code related to that feature in that file.

However, I was still working with the same set of objects and their classes. Still, I wanted to keep all the additions to the classes near to the features that needed to use those additions. For example, when I needed to add another property to a class, I wanted that property to be defined right there in the same file with the logic that used that property, instead of going to the file where the class was originally defined.

This was simple to do because of partial classes in C#. I was able to continue the definition of any classes in that feature file. I added whatever properties or methods needed to exist for that feature to work. Also included were classes that only had meaning for that specific feature and any processing for it.

This would have been possible in many languages, not just C#. It would be simple to implement in any language that has a mechanism to allow open type definitions that span multiple files or any language that supports dynamic types. (It is also possible in languages with closed type definitions, but not as simple.)

What is Feature-Organized Code?

Feature-organized code is code that keeps all properties, methods, and any logic related to a single feature in the same place.

The source files are grouped together by features rather than by class definitions.

Instead of having everything about a class exist in its own file, the parts of the class are defined where they are needed.

Obviously, balance is needed. A good balance is to define the primary set of classes in the “core feature”. These core definitions would basically represent the data of each class by implementing a constructor to create the object and fields or properties to hold the data for that object. Then in the feature files, these core definitions can be extended with calculated properties and methods needed for that feature.

The core feature is concerned about the construction of objects. Other features are concerned about using those objects.

The code to implement each feature could be organized as a single file or a collection of closely related files:

• One file (Simple Features that require only a few types)
• Multiple files with a similar name prefix (In a project with a small number of features)
• A sub folder (In a medium project with complex features that only work when many objects coordinate)
• A sub folder for each app layer with similar naming (In a large project that includes multiple layers that each exist in their own projects: i.e. a Data Access Layer, Business Logic Layer, Application Layer, Unit Testing, etc.)

Advantages of Feature-Organized Code

• Singular Focus

The developer sees only code that is relevant to a single feature in each file. He can focus entirely on that one feature without thinking about the concerns of other features.

• Predictable Locating of Feature Code

Each feature has its own specific place among the many files of the project. Everything about that feature’s implementation can be found in those files.

• Clear Dependencies

Every class and the properties and methods that are needed to implement a feature are all together in the same place. This provides a complete picture of all dependencies required for that feature.

Also, if a feature depends on another feature, that can be clearly indicated in a comment at the top of the file. I refer to these as parent and child features.

• Isolation of Features

The implementation of each feature is isolated from other unrelated features. In many cases, it is even possible to remove an entire feature and all the changes it introduces to the class hierarchy simply by removing those files from the project. This can be done without affecting any other features (except it’s child features).

• Rapid Orientation

Since all code for a single feature is together, a developer can quickly orient himself with the entire scope of a feature. There is no need for him to comprehend the entire class hierarchy of the entire project. He must only understand the properties and methods currently being used by that single feature. This is simple because their definition is right there with the code that uses them. He has no need to dig through multiple files of class definitions looking for the various properties and methods of concern, being distracted and overwhelmed by everything not currently relevant.

In addition, if each layer of the application is organized in a similar fashion he can quickly locate the business logic and data access relevant to that feature. In fact, if the data access layer is segmented in the same way, then he can also see what tables, columns, and other db objects are relevant to that feature.

In this way, a developer can quickly get a full picture of everything relevant to that feature from the database all the way to the user interface.

This is the key to development that does not scale up in cost as the project grows. Whether the project has 5 classes or 1,000, the developer can learn everything relevant by simply looking at the feature files. He doesn’t even need an IDE to help him randomly browse through the code, jumping to definitions that are scattered across thousands of files. He can simply read the files of that single feature to get a complete picture of it.

• Isolated Development

One possibility that this provides is isolated development of features. Because all code for a feature must be in a certain location, developers can easily work on different features without conflicting with one another. Developers can make changes independently and quickly without worrying about who else might be affected by their work. Also, if a change is required beyond the current feature (like in a parent feature), they can communicate those needed changes to a senior developer who can then coordinate how to proceed.

• Secure and Simple Outsourcing

For large projects, a sub project can be created which includes only a copy of the necessary features (the target feature and it’s parent features).

This sub project would greatly improve the performance of the outsourcer because it presents him with only the relevant code. This reduces the likelihood that he will make changes in the wrong location or be overwhelmed by the complexity of a large project.

It also improves security because the entire source code is no longer being passed on to a partially trusted party, nor is it necessary to allow him access to the team’s source control or other servers. This can be very important for large closed-source projects that have sensitive code.

Also, the outsourcer can send his changes in just by zipping up the subfolder for the target feature. This outside code can then be code reviewed just by reading that small group of files without even needing an IDE. (This could even be done on a smart phone through email where the developer in charge of the outsourcing can quickly provide feedback to the outsourcer.)

When the outsourced code reaches an acceptable point, it can easily be merged back into the main project simply by copying those files (likely into an isolated branch in source control). All affected files would be in one location and could easily be code reviewed and tested before being accepted into the main project.

If this were a common scenario, it would even be possible to make some build tools that automate the process of creating these isolated sub projects for a single feature. The build tool would need only a list of features (the target feature and its parent features). Then it could simply include those folders and produce a new project file with references to only those items.

This may even be the preferred means of development for the entire development team. It would greatly improve build times for large projects and would boost developer productivity by allowing them more freedom of control over their development environment. (They could work from home on their own machine for example.) This also introduces great training possibilities for new developers that would help them ease into familiarity with the main project without being overwhelmed by its large scope.

• No Ownership of Code

Because every feature is isolated and relatively small in comparison to the entire project, it also remains as simple as possible.

This prevents ownership concerns in the development team. Each developer works on a feature until it reaches maturity, then he moves onto another feature. Another developer may revisit that feature at a later point to improve it. Because of rapid orientation, any of the developers should be able to work with any feature. There are no hidden dependencies that will remain the secret of the “owner” of that code. Everything relevant and every dependency is contained in one small set of files.

• High Quality Features

It can be simple to ensure that each feature contains every component that ensures high quality: Documentation, conformance to code conventions, unit tests, code coverage, code contracts, a polished user interface to that feature, etc.

A feature would not be considered mature until it reaches the highest standards of your application. It can easily be excluded from release until it can meet those standards.

This compels the development team to complete fewer high quality features instead of many mediocre features.

This brings us back to feature-orientation. Again, an app is nothing more than a collection of features. This focus on high quality features produces apps that users enjoy and will outshine their competitors.

Conclusion

Feature-organization of code is a key to promoting a feature-oriented paradigm for software development.

I will be using this concept in my own development and will later come back with some practical tips on how best to implement feature-organization.

- Rick & Karen Love

5 Hour Apps

I have had many ideas for apps that I want to make. I have started on many of them. However, often after a great start, I start chasing rabbits and eventually lose interest. So I have many unfinished apps. I have a limited amount of time and energy. If I don’t finish a project in a short time, I will likely never finish it.

• What is the solution to prevent losing focus?
• When am I most productive?
• How can I finish a project?

The idea: 5-Hour Apps

I will dedicate 5 hours of free time in a week to publish the next release of an app. This will be done 1 hour a day over 5 days. By the end of the fifth hour the results must be published.
These 5 hours each represent a single unit of work. It will be highly productive by following this pattern:

• Setup a timer for the hour with these increments:
  • 5 minutes
  • 50 minutes
  • 5 minutes
• Decide (5 min): “What is the most productive task I can accomplish in this hour?”
• Code (50 min): Accomplish the task.
• Document (5 min): Document app description, developer notes, update the todo list, and check in the source control.

Again, 5 hours only gives me 5 units of work. Also, in the fifth hour, I must publish the results.

• What can I possibly accomplish in 5 hours?
• Is this even possible at all?
• Why such an extreme limit?

Advantages of the 5-Hour App:

• Single Focus: No fat apps here. I can only produce the sleekest most awesomest apps. I must know exactly what it is supposed to do in order to produce it in this short time.
• Realistic: This is all the time I can give to a side project. It is better to accomplish a small thing than to fail a great thing.
• No Overhead: Everything from testing to publishing must be highly automated in the development process. This process can be improved and reused for each new app.
• Limited Library Coding: Production is focused on the usable app rather than an invisible code library. No longer will I write an “awesome” library that has no real world use.
• No Startup: Because the app is small and singularly focused, the complexity of the project will not require time for me to become orientated with the code. The one hour unit of work will maintain good organization, source control, and planning.
• Extreme Focus: Each hour, the 5 minutes of planning for the next task will give me a focus on the big picture. I will constantly decide what is the most productive route to accomplish that picture to produce a publish-worthy app.
• Publish or Die: The deadline is a true deadline. If an app cannot fulfill its purpose in the time required, it will no longer waste my time. I will move on to another project instead of being swallowed up by the black hole of an infinitely growing project.
• Good Enough But Awesome Software: By focusing on the published result, only the best features will be included. Also, each feature should be well polished. This polish is what separates the mediocre apps from the greats. The short time limit removes the tendency to add features that are unusable by the end user. Because the publish deadline is always near, every feature must be awesome to use.
• A Real Product: No longer will I talk about an app that I am in the process of making. Instead, I can hand my phone to anyone and show them something impressive.

What will be published at the end?

• The app must be published online (most likely as a web-app on my website).
• A blog entry must be made that includes the app link and all details mentioned below.
• Open source apps must have their code uploaded to the open source server.
• A full description of the app must accompany the app which would be suitable for an app store:
  • Summary of the app
  • New features of this release
  • Updated screenshots of the new features
• Developer notes must also accompany the description
  • A summary of the technology and libraries used in the project
  • Any interesting solutions to difficult problems
  • Links to any important research for the project

Automation Tools

Continuous Integration of the Publishable Results

Publishing should be nothing more that uploading files and publishing the blog entry for the release. Any tasks to prepare these files should be completely automated.
In order to accomplish this, all the above is essentially source code. App Description, Developer Notes, and Screen shots will be formatted so that build tools automatically produce the app files and the blog entry.
This will all be done as part of the 5-hour app system.

The 5-Hour App System

The system will be an open source set of build tools and a template project. This system will allow focus to remain on producing value rather than on wasting time with repetitive tasks.
During the first projects, the system will not exist. Everything will be done manually. As the need for automation is identified, they will be noted in the system task list.
When sufficient needs are identified, the initial system tools can be produced. This set of tools and the template project will be a 5 hour app itself.
During a 5 hour project, necessary changes to the system should be noted in the system task list. Then these can be implemented in additional 1-hour increments between 5-hour projects. They should not interfere with the timeline of the current project. If a failure occurs in the system, that part should be corrected manually if at all possible.