Review of "Programing Android" by Zigurd Mednieks

Programming Android by Zigurd Mednieks
My rating: 4 of 5 stars

Want to get into Android programming? What better than a book called Programming Android from O'Reilly! :) This is a GREAT resource! The book is well-organized into sections, giving you information on how to setup your environment all the way up to handling more recent topics like NFC.

I find that the style of the book works well as a reference to look up roughly how you would do something, like setup NFC P2P or setup some OpenGL graphics, as well as a running tutorial to read through to learn how things work. The book is full of code examples (available online too) and valuable information on how to properly implement your applications (see Chapter 10 - A Framework for a Well-Behaved Application).

Reading this book enlightened me to a great way to implement one of my projects without worrying about certain runtime issues. Originally I had considered putting logic in a run loop in the application and shutdown when it left... but that wouldn't work out right when I needed information live, but cached information would be good. The book enlightened me to "Content Providers" which using a service could provide the necessary cache I needed. Later on I discovered that the service by itself would solve my problem, but without the reading, I wouldn't have stumbled upon the path as quickly!

The author, Zigurd Mednieks, has done a great job in writing a strong book on Android to compliment the vast amount of information available through Google's documentation. I suggest you get this book, especially the eBook form - you can easily search through and find references / copy code-bits.

The eBook format of this book was provided free through O'Reilly's Blogger Review program, you can purchase the book from the O'Reilly book store at: http://shop.oreilly.com/product/0636920023005.do
You can support this blog by purchasing the book through Amazon at: Programming Android
View all my reviews

Review of "The Manga Guide to Relativity" by Masafumi Yamamoto, Keita Takatsu, and Hideo Nitta

The Manga Guide to Relativity

If you have a curiosity about physics, this is a fun way to sate it. "The Manga Guide to Relativity" by Masafumi Yamamoto, Keita Takatsu, and Hideo Nitta is a beautiful blend of manga, humor and science.

I had this book for quite some time and decided to try to get through it... little did I know that I would finish it in only a few hours of reading! While I understood some of the concepts at a very high level, some of the paradoxes and details typically got me. This guide's illustrations make the complex issues easier to grasp, while the chapter reviews help explore the topics in a little more depth.

Even though the manga was constructed with the intent of explaining the complex concepts of Special and General Relativity, it did not deviate from the tried-and-true manga recipe: bizarre scenarios, extreme characters, and strange character appearances.

The ebook format was well-implemented and worked beautifully on my Touchpad. While some PDFs choke due to overly complex layouts, this manga was smooth to navigate and rendered beautifully. Anybody used to reading mangas using "Perfect Viewer" on Android should install the PDF plugin to read this, it works great in two-page mode.

This ebook is a great read and its quality entices me to check out the other books in the "Manga guide to ..." series. If you're a high-school student just getting into physics or a manga fan looking for some intellectual fun, this book is a perfect addition to your collection.

The eBook format of this book was provided free through O'Reilly's Blogger Review program, you can purchase the book from the O'Reilly book store at: http://shop.oreilly.com/product/9781593272722.do

You can support this blog by purchasing the book through Amazon at:The Manga Guide to Relativity

View all my GoodReads reviews

LuaJSON 1.3.1 Released

LuaJSON 1.3.1 released! If you use luarocks, just use luarocks install luajson since it should soon be in the repository.

This release's changes include:

• Documented and tested compatibility with Lua 5.1, 5.2, and LuaJIT-2.0-beta10.
• Documented and tested compatibility with the 'classic' strict module on Lua 5.1 and LuaJIT-2.0-beta10 as provided by the LuaJIT-2.0-beta10 package.
• Tested after-the-fact compatibility with Penlight's 'pl.strict' module for all supported Lua versions.
• Fixes supplied by François Perrad included to address problems found in 'strict' library handling.
• Users of the direct 'json' module will have a polluted global environment with the 'json' module populated unconditionally.

If there are any other Lua environments that you would like added to my test matrix, please let me know. I am always open to suggestions and improvements. I host the project on github at https://github.com/harningt/luajson, so feel free to fork and submit merge-requests :)

A note on the 'json' module pollution: if there is a general consensus among users of the library (wherever they may be), I'll happily remove this pollution. I much prefer Lua 5.2's way of handling modules and don't mind the fact that creating a Lua module without the 'module' function has the side effect that Lua 5.1 doesn't even have the global pollution.

Long-Delayed Updates - Life, Projects, Work

I've been putting off updates here for quite some time, primarily due to lack of focus. I've been working on quite a few personal things lately:

• Attending free college courses on cryptography and algorithms
• Working out the design of the cryptoface library
• Getting my feet wet developing mobile/desktop games with Moai
• Beta testing games

On the work/career side, I've been busy as well:

• Designing a new cryptographic data interface
• Designing a new memory management interface
• Implementing a new web-request client
• Attending people/skill-management training
• Answering recruitment messages

While working on designing a new cryptographic data interface at work, I've had a chance to get a better handle on how certain sets of operations should behave and how one might best structure a generic system. This should help out with figuring out how to best setup how cryptoface will work out.

I also had to design a memory management interface... that was quite an eye-opener. The main objectives were to ensure that data in memory would not get flushed to disk and that any flushable memory would be protected. This issue of flushable memory was relatively easy, use unflushable memory to store a key to encrypt the flushable memory. The unflushable memory was difficult and yielded a problem: What about suspend-to-disk? It turns out that, for the relevant systems, on a suspend-to-disk operation, your 'unflushable' memory will end up on disk (unless you implement some crazy notification system that 'might' be implementable on a given platform). I plan on writing a larger article on how the memory management interface will make its way into cryptoface.

Earlier this year I attended free online courses on cryptography and algorithms. These were awesome, they took much more time than I anticipated, but they stretched my mind quite a bit. I was thinking that, given I work on cryptography so much, it would just be a refresher course. Not at all! I was also better prepared for analyzing the recent "padding oracle" attacks that have come up lately. Taking the algorithms class was a great refresher and helped give me a better appreciation than I did when I first had it at MSU as a freshman.

Recently I came upon the Moai development framework. It strikes me as a great fit of technologies:

• Lua
• Android
• Chrome (via NaCl)
• Desktop (Linux/Windows/OSX)
• iOS

Unlike many of the other frameworks out there, it is open-source! I took advantage of this during my exploration of one the physics system in place (box2d) and used some free time to patch it up with some documentation and unify the scaling system to better honor the virtual unit system. I plan on using it sometime in my free time to develop and publish a game for Android for my kids to play. What cooler way to get kid-kudos than be the one with the dad who "wrote a video game!"

This open-source experience also gave me an interesting insight into an area that I had not yet ventured into: getting approval for "outside" work. My prior long-running projects were grandfathered in through the acquisition process, but I had not yet envisioned writing game software.

I have also had the task of answering many recruiter messages on Linked-in. For the longest time I was receiving many opportunities that involve moving out to an area w/ at least double the cost of living... not my cup of tea... at least yet. (Quick stats from a site show that moving to California would cost me 55% more and I would only be making 25% more... not cool) I discovered about a month ago that there was a section to input text for recruiters/etc to see when considering to send a message. Lately I haven't heard from as many (yay!) but a few received still seem to not read this. I also typically get requests to forward this information to any I may think fit-the-bill. Sorry... even your offer of an iPad on recruitment pass-through isn't going to work well. My current network of people is pretty much where I'd like them to be: local! In addition, most of the talent I know well and would recommend well are those that I work with (a great team!) and dare not trade them off in return for getting someone new (though are two new contractors look to be doing quite well).

On the receiving end of this when observing the contractor-search process, it looks like the hiring process for skilled individuals is extremely difficult. It seemed the process was to funnel people through that look like they "might" have qualifications. We ended up with people who lacked entry-level computer science skills... quite annoying when we have 3rd party hiring staff "pre-screening"... as the smaller TrustBearer Labs, I was more involved and had to directly deal with such individuals, but at least then it was more understandable since we didn't have a big arm to work on the screening task. Not to dismiss the recruiter's negligence in the hiring process, it seems that the pool of qualified skilled software engineers is getting quite diluted... Which will make it a bigger challenge for me if/when I ever enter the active employment search role: I'll have to fight to differentiate myself from the crowd of others out there. At least there are sites out there that are trying to help in this area:

• Nerdability - My profile is http://nerdability.com/user/harningt
• Github - My public page is https://github.com/harningt

These work well since I do like to work on open-source software. Yet another benefit to the open-source industry, if you write good code, potential employers can see it before you work for them!

Hopefully this blog post will put an end to the long blocker on writing more posts.

Goodbye PGP Global Directory Key - Hello Mountain View

After discovering that the PGP Global Directory has been spamming my public key biweekly w/ 2-week signatures (see here for a snapshot of keys), I trashed my account there to put an end to that.
At first I thought the email threads about keyserver spam not being a big problem, I'm seeing how it could easily be a problem without it technically being spam. Hopefully a good solution comes about so that owners of keys could sign requests to remove keys from the signature list. I'd guess such a solution would restrict what sort of signatures be removed (ex: signature revocations couldn't be removed, etc).

Putting out my key-signing policy appears to have worked pretty good for getting keys signed, so far have 3 cross-signatures out of it. Hopefully I can get some more signatures this year.
If anyone in the Mountain View, CA area wants to work out a key-signing arrangement, I'm out there on business ~January 23-27. Could possibly work out my first signatures of the "Level 3 - 0x13 - Careful Check" type mentioned in my Key Signing Policy :) It is pretty trivial to get a Level 3 key signed, basically just need keys pre-exchanged and ID (driver's license, passport, other government ID).

LuaJSON 1.3 Released

LuaJSON 1.3 is released to the wild!
Major changes made:

• new 'nothrow' global option - currently a trivial 'pcall' hook on decode, but could later resolve to a more efficient handler
• enhanced error output from the 'next' branch
• hopefully "stackless" parser - limit of parsing depth now as large as heap and not stack

Rockspec for those using LuaRocks if it hasn't hit their repo yet: https://raw.github.com/harningt/luajson/b7cb1e6221ae6b70b208b242c1654da39087230d/rockspecs/luajson-1.3-1.rockspec
GitHub link for signed tag: https://github.com/harningt/luajson/tree/1.3
Release download tarball: https://github.com/downloads/harningt/luajson/luajson-1.3.tar.gz

The "stackless" parser is basically a linearization of the LPeg parser so that it parses JSON tokens and passes them into a stack/state-machine implemented as a Lua state object. This degrades performance slightly in the pre 1.2.1 era, but removes C/LPeg stack depth problems encountered in all prior implementations (including the abominably slow 1.2.2 version that reduced the problem, but didn't solve it).

While profiling performance, I found that some unrolling versions seemed to be a wee bit faster, but used more memory and had more pagefaults. My focus on future releases of LuaJSON will be on speed, including a possibility of 2.0 release breaking compatibility in the interest of getting > 2 MB/s JSON parsing performance. Looking at the strict YAJL parser - it hits >100 MB/s on the same data where I get 2 MB/s at best. If I can pull in an MIT-like-licensed C-based JSON parser into Lua and get >= 10x performance, I may add an option for the parser to try to consume the other parser under the LuaJSON interface (for uniformity).

Later I plan on enhancing encoding performance, but for the time being, decoding is most important right now.

CryptoFace Digest Design Oops

Designing an interface for managing a library of cryptographic digests seems so easy, right?

Select a digest from a list, process data, get a hash... all there is to it, right?

WRONG!

While pulling in another digest provider, Botan, I found some items that did not fit into the simple model. Namely the configurability of some of the uncommon and new digest algorithms:

• Customizable output size of the 3 Skein internal storage variants
• Customizable "personalization" value of Skein
• Custom number of rounds and output size for Tiger
• ...

This is even without the notions of composing digests in various fashions, such as in parallel or in a Feistel scheme.

In light of this, I anticipate changing my mechanism for obtaining and enumerating digest implementations. Changes will likely include moving the enumeration of digests to more of a secondary feature, making the move to a set of 'well-defined' digest identifiers to be mapped from strings, and making way for parameterized construction of digests to accommodate more complex notions, including hash-based MACs/etc.

The change will not be without complication, however in light of analyzing the problem and the Botan library, I think I may be able to make some elegant structures possible for dealing with complex algorithms... at least with the Lua engine. An example set of structures could be:

-- Simple sized sha2 filter
x = Filter(SHA2(256))
-- HMAC
x = Filter(HMAC(SHA2(256),"KEY")
-- Complex chain of hashes
x = Filter(Parallel(SHA2(512), Skein(512,1024,"Personalization")))
-- Take the filter and stream file-to-file using ltn12
ltn12.pump.all(
  ltn12.source.file("SOURCEFILE"),
  ltn12.sink.chain(x, ltn12.sink.file("SOURCEFILE.hash")))