Core S² Software Solutions

oDataiOS is a clean and simple oData library for the iOS platform! Finally, something to replace the existing huge monolithic OData4ObjC. The main driving force for this programming effort was the need for a futures / promise asynchronous programming-model to integrate with my TrackAttack app.

TrackAttack, like many operating systems, does not (by default) separate the thread which executes all GUI events, and a thread which executes all the code you write. Simply, if you are interacting with the GUI (say, updating a text-field), you must not only execute that on the main (GUI) thread, but also must do it quickly since you don’t want to block or slow-down any other necessary GUI events. Thus, all potentially-blocking work must be off-loaded onto other threads.

All of this is basic “App Programming 101” knowledge, so tackling the problem isn’t anything new. What’s new is the use of “promises & futures“: a simple but incredibly powerful solution, blowing all of my previous multi-threading programming experiences out of the water. The idea is pretty simple: you tell some sort of management object that you would like to execute several tasks (sometimes as simple as several functions), which may or may not have some inter-dependancies, and to pass on the results to a specific function you want. Essentially it’s a dispatching service, with the subtle twist that you only get what you need when you need it! Thus, you can dispatch work from the main thread, allowing the GUI to continue its work, and only when your dispatched work is completely done, will it intercept the GUI thread and insert new data.

Usually, spawning new threads and transmitting data between them has been a huge hassle, especially in native languages where there is nearly no true functional-language support (so kiss closures and lambdas farewell). Doing so with Objective-C is simplified, but locks are still required, which can lead to some horrible debugging sessions.

In the end, I was able to solve my problem (which was grouping up several blocking data-query calls for the oData interface) by mixing the powerful code-block execution manager in Apple’s Obj-C Foundation framework (named “NSOperationQueue“) and writing a high-level dispatch manager class.

The end-result is the first-draft release of oDataiOS! Currently it implements all of the basic interfacing methods for an oData server, but also allows you to do blocking and non-blocking (async.) calls. Though I’m still working on implementing a mode to allow dependency checking (currently, all commands are executed, even if there is parts of data never accessed). Since this is also a first-draft, quite a bit of the code is changing, but community feedback is always appreciated. My next big task I’d like to work on is inserting some more formal unit-tests, since there is a huge variety of tests that must be done to verify data consistency. Type-checking in oData is slightly inconsistent, since some oData services that run on top of a MSSQL database may have the same type-name, but different encodings. Regardless, the code is pretty flexible, and easy to read, so changing the code for one preference over another is a quick-fix.

On a final note, many developers who come from a strictly imperative programming language background may not understand how this is different from just launching your own threads and waiting for the threads to finish. In-fact, they are quite similar! The differences that make promises / futures powerful is that it is a clean and self-contained method of receiving the resulting data (no need to lock-down threads to copy data over, since it is implemented internally), and you never have to check for completion: you’ve already provided the code-block to execute upon completion, so you’re good-to-go!

Grab the source-code here!

Last Month I released a self-published book titled “3D Computer Graphics: Software Revealed“. I’ve worked on it on and off  starting about two years ago, with a full re-write beginning six months ago, and a second edition coming in a few short months! It’s been a long adventure to write something I feel comfortable enough publishing, but it was absolutely fun and well worth it! Just like when I tutored friends for various computer-science topics, doing this activity was a great way to better understand a topic. I specifically remember working with friends in my undergraduate systems-programming class learning on how alerts, handles, and system-calls worked. I learned faster in that situation than I could of by just sitting down and reading a book or even attending a lecture or two! This book was a great way to achieve the same effect: by writing down my initial thoughts, and then reviewing them against notes from classes, books I own, and the ultimate help for answering random questions or research: Wikipedia. Overall, it was a great experience, but not without some lessons learned on the experience itself. Let me elaborate a bit more on what I’ve learned:

On a quick tangent, please consider donating to Wikipedia; it was an enormously helpful source during my studies and work on this book. Without Wikipedia, it would of taken a substantial more amount of effort to finish this book! Donate or contribute your time – I’ve done both, so should you!

Developing material is easy, writing to and audience isn’t. The easiest part of writing the book was the actual act of putting down material, either by writing code, text, examples, or random thoughts that I later merged into the appropriate sections. When it comes to turning this raw material into something worth reading, that’s where the real challenge comes! The process of taking your material and making it easy to read and understand is difficult because important ideas are simple and bland, nothing exciting for the reader to see. If you do make something more interesting, you can fall into the trap of over-complexity! You have to make sure every idea is balanced: easy to follow, yet interesting, but complete enough to be an independent thought for the reader to grasp. Writing your material as though you are presenting it in an excited voice really helped me: saying “barycentric coordinates are an easy way to map textures to 3D surfaces” is plain and overly simple, and thus completely uninteresting. What I did was follow each new subject with a clarity of purpose and application:  “barycentric coordinates are not only easy for all types of texture-mapping (textures, bump-mapping, specular maps, etc.), but the related math operators are quickly executed with parallel floating-point hardware”. The language is still bland, but the reader can at least immediately gauge the importance through the mentioned application. For every one sentence originally written, I must of at re-written it twice trying to add clarity or interesting relationships. For technical subjects, I also found it very helpful to constantly relate ideas together: if I mention texture mapping in the previous subject, and I introduce secondary texture maps (i.e. bump-mapping), I might write and independent section explaining all major texture maps used in professional model-skinning. My favorite part of a new tech-subject book is just skipping around and looking for those “Coding Horror” bits like in Code Complete.

I’ve learned to explain every idea in three ways: first conceptually (definition), then through procedure (math / steps), then through application (code). Much like the first point, where writing to an audience is much more challenging than writing the core content, I’ve also learned how to better explain ideas as a whole. While working with friends and tutoring in college, I realized that there are several ways people prefer to learn. I’ve never taken a formal “teaching” course, but with the power of Wikipedia I did learn about teaching methods. Many of the methods boil down to two groups (this is a simplification, but I still found it helpful): logic-based learners (learn as though the idea is a procedure) and application-based learners (learn through example and how the idea is applied). In my book I tried to do both with a middle ground: I always tried to define the idea as cleanly and as independently as possible, then I explained any sort of steps or dependencies of the idea, and finally I always provided some sort of example or code. Doing these three, I believe, works well in explaining all of the core concepts, and reinforces the material for the reader.

Time: takes huge effort and time to re-read material. I hate to sound like a broken record, repeating much of what I’ve already said, but… writing to an audience is hard! It’s hard because much of what you write has to be edited, reviewed, re-written, re-read, etc. This takes a huge amount of time. For better or worse, I spent a significantly more amount of time editing than writing the original material. It also pained me that some time truly does get wasted: I wrote much more than what was in the final version of the text, simply because the text had to be re-written or wasn’t in the scope of the book. What’s interesting to note is that this “lesson” I learned is a true lesson in software engineering: it’s impossible to plan your efforts perfectly, and naturally you will waste time on some feature or block of code that gets removed, changed, or re-implemented.

Distribution is easy, Marketing is hard. I chose to distribute the book through as many mediums as possible, and only spend time for marketing but no real cash. Setting up book sales through Amazon (eBook version), CreateSpace (physical version), and PayPal (PDF version) is fairly easy. There are some hoops you’ll have to jump through, though nothing unreasonable. My only disappointment was that Apple doesn’t allow self-publication through its services, but you can use third party publishers (which are as difficult as Apple was). I never tried to reach out to a formal publishing group simply because I’m well aware of how challenging it is to publish a book and the costs associated with it (I’ve talked to a few professors who have published books – it’s a crazy-nasty business, with authors not getting their fair share back IMHO). As for the marketing itself, I only focused on social-media (thank you Reddit!). It’s free, easy to use, and fairly very quick to push sales! In one day’s worth of marketing on Reddit (by simply posting two submissions), I grew my daily average traffic by 3,000 unique visitors and sold about 40 copies. The day after I sold about 20, then about 10, and after that the sales went back to the regular trickle. Am I making money? Yes! Will it pay back the time and effort put in? No, but I don’t care about sales – I cared more about the experience the the satisfaction from having the physical book in my hands. I’ve now started a secondary marketing push to professors, which seem like the next logical step. I’ve now have two professors who have my materials listed to their students in the course description / class-sheet. I’ll have to now start reaching out to other universities and professors I may not have any relationship with, but it’s at minimum a great way to push out my name. Google Analytic has also played a huge roll in better understanding who is visiting and who is buying! I’m not surprised by any of the data (i.e. most sales are in America, Germany, and France), but it’s a great way to really quantify and track the results of any efforts I do.

    

On the left is the Reddit-driven spike, the big focus on my initial marketing push. On the right is the average web-traffic, which consists of around 20 to 40 visitors across all my sites (this blog, my other projects, and my source-code repositories).

Listen to feedback, and always talk to your readers. Readers are great: you’ll  always get feedback if you ask people. In general my feedback has been positive, but with a few suggestions for smaller changes. Even negative feedback still contains some gems! I know that for my next version of text, I’ll have to introduce two new sections to clarify a general idea (translation and rotation), as well as improve a weak section (introduction and origin of the 3D rotation matrix). Minor errors like broken links, spelling, and grammar are also getting caught – it’s amazing what a group of readers can find, even if I’ve re-read my material many many times. If I get enough sales, I’ll absolutely do what Dr. Knuth does with his $2.56 error-finding checks! (Which reminds me… I really need to buy his “Art of Computer Programming” series). Finally, this is a one-man operation: I want to make sure that if there are questions or comments, I actually talk directly to the readers. There are no PR agents or sales people between me and who buys the books – not only do I like to listen to what people say, but I’m sure it gives a positive affect on readers knowing the author explicitly pays attention to them. It’s a win-win as well: it continues the education-enforcement cycle, where if a reader has an issue or question, then clearly I haven’t done my job well enough, and I can in-turn improve my material and potentially learn something new myself. Open-sourcing the code on a platform that’s easily accessible and guaranteed to stay has also really been successful, with positive reader feedback: the 3D Tutorial source-code GitHub page isn’t on any weird or unique URL like many books unfortunately do. It’s easy to access, and no big zip-file download is required: code can be viewed and executed in the reader’s browser!

What’s next? I’m currently working on a presentation and hand out material for an iOS developer course I’m teaching through the ASUW Experimental College: the University of Washington’s “teach your own class” program. Though I could write a book on this subject, I’ve never felt happy with the general concept of books-on-ideas-and-not-one-idea. This is because not only does the content constantly change (iOS tools, submission process, etc. are evolving in big ways with every release) but because a pair of specialized books are still better introductory materials than a high-level book on everything. I’m a big fan of quality vs. quantity in terms of reading.

After teaching the ASUW course, I’ll be attempting to write a memory-management book, which is a subject I find very interesting! It’ll be much longer than the 3D-tutorial, and have much less maths, but will have more programming-language discussions and case-studies on real-world applications. This subject isn’t saturated with reading material, so there is absolutely a market need for it! Hopefully I can start getting physical copies to show up at universities – a programmer can certainly dream of it ;)

All in all, well worth it. Thank you very much readers, it has been a blast doing this little project!

I’ve recently written a little application for Windows 8’s Metro-App platform: let’s call it Win8 Apps platform for the sake of brevity. Metro isn’t new (Windows Phone came out a few years ago), but it’s now part of Windows 8, thus going to be widely adopted as the de-facto desktop interface. My application is a simple slide-to-navigate image album: it allows portrait and landscape images (without zooming – more on that later), and allows embedded videos. Touching video-images once plays a video, and touching it again pushes you back to the regular image album view. Checkout the source code here at GitHub, or just fork it and have fun making your own changes!

After programming on Android and iOS for a few years, I can modestly judge that Microsoft is finally going in the right direction with their new Windows 8 App platform from the developer’s perspective. I can’t stress enough that my perspective written here is purely from a developer’s point-of-view, and not from a business or user’s view. I’ll go as far as saying that Metro isn’t the right GUI solution that the average user needs, though clearly computer interfaces and experiences absolutely need to be simplified, so in a sense Metro is a move in the right direction. Regardless, you can still flip to a classic desktop, so users aren’t forced to commit to anything. I wont go deeper into this subject, but solutions like Google’s Chromebook are the best approach for the average consumer (though enterprise solutions are still a Windows winner). The average computer user really just needs a browser, which has only become increasingly powerful as business apps (Office, Image editing, etc.) are popping all over the web.

Now down to the core discussion: how is it to program in the new Win8 App environment?

The Win8 App platform succeeds by implementing a clean platform and tool-suite: its new run-time environment, libraries, methodologies, and interfaces are all independent of one another and well modulated. All the classic .net languages (C#, VB, and VC++) are ready-to-go for app development  with the added new language Javascript! What’s particularly nice is each language embraces their respective strengths, but also doesn’t stray too far away from a general standard that the .net library provides. I felt that Javascript in particular overly embraced lambda-functions, but the end-result is always the same. The library namespaces make sense, though Microsoft (and this is a common fault with their past .net versions) has overly embraced object-oriented programing (OOP).

There is almost an over-modularization of components and classes, an annoying fault also found in the Java SDK libraries. Something as trivial as setting how long an animation lasts should take a native type (float, for seconds). Instead, the type required is “Duration”, which can only be constructed with a “TimeSpan” object. Alternatively, you can construct “Duration” with a “TimeSpan” static function that converts seconds direction to a TimeSpan. Clearly these classes are needed in a variety of other applications, but not necessary for a simple argument like an animation’s time. This is only the tip of the iceberg; there are many, many other abuses like this, which I call “object-oriented verbosity”. Another frustration would be that over-abstraction of clases: the UIElement class (the base type for renderable / interactive screen elements) does not directly provide position or size, but instead provides a matrix which may or may not be a pointer to a specially-derived matrix with the properties you want. What this means is that if your UIElement is rotated and translated, but you have yet to define a size, the matrix object owned by UIElement will strictly only have the rotation and size properties. It is critically important for any GUI library to be as up-front and accessible as possible, regardless of backend or platform.

Though the language-model/library interface is a bit weak, at least the XML-language forms make up for crazy-easy development. Past platforms with Microsoft commonly had a form-modeling editor, like a GUI mockup system. With .net, you could place a button, double-click on it, and have code auto-generated for you! Microsoft has done this well, but the older form-editor were just visual tools, not something easily changed through text (a small difference, but a huge impact on development time!). Now I can cleanly move a button either in the GUI editor (now a separate tool!). Want to catch when a user clicks a button? Just set the button-tag’s “PointerPressed” property to the name of your function. All of this really conforms to the Model–View–Controller: often dismissed as boilerplate code, this approach to GUI-programming is incredibly important since mobile platforms (Win8 Apps included) re-use many screens and are quick to change forms, fits perfectly with what is required in development.

An aspect that I couldn’t decide if it was good or bad was the inclusion of CSS style-definitions in GUI forms. XML, much like HTML, lays out a document’s content, but shouldn’t define how these elements look in-line since many styles are often repeated. Thus, a CSS file makes sense, yet, if the platform has committed to an alternative to HTML, why not commit to replacing CSS with a less verbose language? CSS is powerful, but often hard to read and maintain – it makes more sense to allow some sort of repeatable style definitions within the source XML, or at least have the ability to include other XML files in-line. Then again, if developing an Win8 App is more like developing a web app, at least there is a strong and large shared-base of knowledge all over the web.

Overall, Microsoft has done a great job simply because they are committing to the right direction: cleaner developer tools, a new XML layout system, and all based on the powerful .net platform. There are apparent weaknesses, such as the difficulty of programmatically moving content, which is trivial for Android and iOS. Microsoft simply needs to refine the platform, improve documentation (it was pretty hard to distinguish between this new platform, code from older .net versions, and Silverlight APIs), and most importantly: get the average consumer using Windows 8!