How to make an eBook
(blogarhythm ~ Land of a Thousand Words - Scissor Sisters)
So eBook sales have surpassed hardcover for the first time, and it is no surprise that the rise of the tablets is the main driver.
There's something quite comfortable about having a nice digital bundle of information at your fingertips, like warm buttered toast.
With relatively open standards and the ubiquity of ereaders, the ebook has become ideal packaging for all manner of information, from training manuals to open source project documentation. Or even that book that apparently 81% of us believe we have inside.
So how do you make an ebook? My first thought on searching for options is that we are pretty spoiled for choice. But there are important caveats to note, like how Apple iBooks Author can only publish in full fidelity to iTunes Book Store. And we can't get far before needing to study up on the various formats out there: EPUB is widely used, but not without its criticisms and edge-cases especially when trying to push the boundaries with multimedia and social aspects; the Kindle and other ereaders expect Mobi; and Kindle Fire introduced the KF8 format.
The good news is that producing pretty standard EPUB, Mobi, PDF and HTML variants of your book can be done very easily with a range of commercial and non-commercial tools. It's even possible to build an EPUB by hand with just a text editor if you are game.
I started to experiment with some open source toolchains to see just how well they work in practice. Personally, I'm liking the simplicity of using pandoc to build a range of output formats from markdown source files.
My experiments are in the eBook Toolchains project on github if you'd like to examine the various approaches I've tried. Have you tried something that's not there? I'd love to hear about it - comment below or better yet, send me a pull-request on the github project with your examples added!
read more and comment..
Vale Conversations Network
(blogarhythm ~ end roll 浜崎あゆみ)
So I just listened to the last IT Conversations podcast of all time All's Well That Ends Well.
I'll miss the curation they provided. Did you know that 8 out of 10 interesting facts I quote at dinner parties I learned on the network? ;-)
And still learning: IT Conversations was the 2nd podcast ever? Apparently Doug Kaye uploaded a feed the day after Dave Winer posted his first example of using the RSS enclosure tag.
I'm not sure the Conversations Network couldn't have remained relevant and valuable for years to come, but it is an admirable decision to go out on a high and close down gracefully - importantly taking the time and care to ensure that the content archives remain available indefinitely.
read more and comment..
Building C# on MacOSX with Sublime Text
Fortunately, no dramas. The mono team have made it a very smooth process. I simply downloaded and installed the Mono SDK (it is packaged as a standard disk image [.dmg]). That's enough to compile and run simple projects.
$ mcs hello_world.cs
$ mono hello_world.exe
There's a whole cross-platform IDE available now called MonoDevelop and it looks great if you are doing serious C#. Right now though, I was happy enough to build from the command line .. or from my favourite editor of the moment, Sublime Text.
Setting up a C# build system is trivial. From the "Tools | Build System" choose "New Build System..." option. My version simply associates with all .cs files and passes them to the mcs compiler:
{
"cmd": ["mcs","$file"],
"selector": "source.cs"
}Then when you are in a C# file you can simply ⌘B to compile. Like this:
Blogarhythm: Because It's There - Michael Hedges #NP
read more and comment..
The Full Monty - from Ruby to Python n00bie
Ruby developers are a pretty spoilt bunch these days. The community has overall done a great job of rolling many of the advances in modern development practice into the tools and conventions we unconsciously put to work every day.
It was a casual discussion about testing that re-ignited my interest in taking a peek over the fence. I picked up a copy of Greg L. Turnquist's Python Testing Cookbook and enjoyed playing around with a couple of the Python testing tools. It's an excellent book for ramping up your testing skills with Python - eminently clear and practical.
I was pretty sure that if any language community came close to matching Ruby's approach to development it would be Python. But is that true?
Most comparisons of Ruby and Python (like here, here and here) focus on language syntax and features. Conclusion?
same but different!What I find more interesting is a comparison of the fundamental productivity patterns used in each community, assuming your goal is to produce high-quality code that can be reliably distributed or deployed, and likely makes liberal use of other - probably open source - code components.
So here is a rundown for some of the common patterns I could not do without when developing in Ruby, and what appear to be the leading Python equivalents - according to my research as of Oct-2012, but I welcome corrections and further information from any Python experts out there!
Environment Partitioning
We don't like dependencies from other projects leaking over to contaminate and confound what we are trying to work on. While you could run up a separate VM for each project, it is much better if you have tools that can keep installed libraries and even the language distributions separate for each project.The Ruby Way: rvm is the leading tool for creating isolated ruby and gemset environments. A less intrusive alternative is rbenv (compared here).
The Python Way: virtualenv creates isolated Python environments. Ref: SO.
Dependency Management
It is likely our project will make use of other packages. We want automatic dependency management so that we can easy deploy predictable compositions of code packages.The Ruby Way: bundler
The Python Way: pip with a requirements.txt file. Ref: SO
Reusable Code Packaging
For anything more than trivial scripts, we probably want to package our project so that it can be reliably distributed or deployed.The Ruby Way: we use gems. Easily built by hand, or bootstrapped with a tool like bundler or jeweler
The Python Way: use setuptools (enhancements to the Python distutils) to build and distribute eggs. Ref: SO
Reusable Code Distribution
Both Ruby and Python are very open-source oriented programming communities. Not only do we consume a great deal, but it's likely we'll often want to make our own contributions easily available to others.The Ruby Way: RubyGems for distribution, with source code most often found on github.
The Python Way: pip. And source code also seems to be showing up more on github than historical use of svn repositories. Ref: quora
Project Build Tool
We'd prefer a common approach to running project build, doc, install and test tasks rather than rolling our own for each project.The Ruby Way: rake.
The Python Way: this one I'm not so sure of. It seems most projects simply provide a custom setup script using distutils, but there are a variety of projects that support more complex build requirements. Ref: SO
Automated Testing
It's 2012 already, we know that automated testing is a cornerstone of quality software. Especially so for code that is going to be widely shared and reused. Whether you do TDD, BDD or simply unit test, we all have a good test framework or two on our toolbelt.The Ruby Way: Test::Unit, RSpec, Cucumber amongst others. It is extremely rare to find a project these days that doesn't have tests of some flavour.
The Python Way: unittest (sometimes called PyUnit) and doctest are common frameworks for unit testing and TDD. nose is a test runner, especially good for non-trivial projects. Lettuce is the rough Python equivalent of Cucumber. Like Ruby, there are many other projects to assist testing such as mocking tools like Mockito.
Bonus: open source projects have been rapidly adopting Travis for automated continuous integration on the back of a github commit. And it works for Ruby and Python.
Blogarhythm: Always Look On The Bright Side Of Life - Eric Idle/Monty Python
read more and comment..