Goodbye Pelican, Hello WordPress!

First of all, sorry for all of those who came here through Google, and were redirected to the homepage. I tried my best to preserve URLs but I couldn’t figure out a great way to do that.

For recurring readers, you may have noticed the site has changed. That’s because this blog is now powered by WordPress!

I’m generally not a fan of heavy-handed systems, but the user experience eventually convinced me this was the right route. I’m now using WordPress, and even the paid edition.

Why I chose WordPress

WordPress as a platform provides a lot of tools to simplify the blog authoring experience. With Pelican, my blog writing experience was the following:

  1. Create a new file in restructured text, add some boilerplate
  2. adding images requires copying the image to the images/ directory, then adding the image link by hand into the file.
  3. re-rendering the post over and over again.
  4. calling the execute script, which handles publishing the files to Github.

The disadvantages of the platform were:

  1. The iteration was slow, including the ability to quickly add and manipulate images.
  2. The experience was on desktop only, and Git to boot, so I had to have enough time to clone (or pull or push) a git repository and fire up a text editor. Not great for just jotting down a quick note.

WordPress reduces this whole process, and support both mobile and desktop:

  1. Create a new post in the UI
  2. Add images by just selecting the file. I can do basic modifications like crop and rotate directly in wordpress.
  3. click “publish”

Overall, the reduced friction has let me write posts more frequently, as well as use it as a bed for notes in the meantime.

There are also other benefits:

  • several themes available so I can quickly style.
  • mobile app
  • SEO friendly

And probably features I’m sure to discover as well.

So, welcome to my new WordPress blog!

Book Report: The Blue Zones

About the Book

The Blue Zones discusses areas across the world where people live unusually long, fulfilling lives. In these regions, the rate of people reaching 100 years old three times as many as those in the USA. In the book, author Dan Buettner states that studies on twins show that roughly 75% of the factors that play into longevity are environmental, with 25% genetic. As such, a change in habit or behavior can have a significant impact on one’s quality of life, and how long they live.

Dan then goes into each blue zone, and discusses the factors that are likely to play into their longevity.

Keys to Longevity

Reading through the four regions (Sardinia, Okinawa, Adventists in Loma Linda, and Nicoya), there are several common themes. I’ve grouped them as such below

Mostly Vegetarian Diet

A diet heavy on beans, vegetables (especially green, leafy ones), and nuts are common elements across all the regions. Each group consumes their set of vegetables regularly, and many include superfoods that are known to help prevent inflammation and cancer.

In the Adventist Health Study, a survey of thousands of Seventh-Day Church Adventists in Loma Linda, California, vegetarians had a 2 year longevity advantage in the study. In the same study, nut eaters had a 2 year advantage.

Regular, Moderate Alcohol

All of the regions drank alcohol regularly. Sardinians in particular drank Cannonau wine, a local variant that has three times the flavonoids of regular wine. Flavonoids help reduce inflammation, and risk of cancer, stroke, and heart disease.

Regular Tea and Coffee Consumption

Throughout the day, everyone drinks a significant amount of tea and coffee.

Reduced Added Sugar Consumption

The added sugar consumption of most surveyed is under 25 grams, half of the daily added sugar recommendation of 50 grams. Many only take added sugar with their coffee.

Sufficient Sun

The book calls out the significant amount of sun that the older generation of Okinawan get, with several hours of time out in the sun harvesting and growing vegetables.

Sufficient Water

In the Adventists in Loma Linda, Men who 5-6 glasses of water per day had a substantially lower risk of a fatal heart attack. Drinking increased soda, coffee, and cocoa resulted in a much higher fatal heart attack rate.

Physical Activity

In the Adventist Health Study, physical activity (30 minutes 3 times a week) resulted a 2 year longevity increase and decreased incidence of heart and stomach cancer. Modest activity and the benefit levels out at the marathoner level.

Eat a Light Dinner

Eat a light dinner. There’s no studies that support this, but it is common across all the regions for the dinner to be light. Most calories are consumed by noon, for those living in the region.

Have a Strong Social Network

All of the citizens in the region had a strong social network, visiting each other regularly. The feeling of need and purpose was common for all of those interviewed.

Thoughts on the Book

The Blue Zones was a pleasant and easy read, mixing in individual interviews and Dan’s perspective with discussions around specific behaviors that may contribute to longevity, with studies and summaries near the end.

From a statistical point, correlation does not always equal causation, and it’s important to keep that perspective when reading the book. The book highlights multiple behaviors that are linked to increased longevity, but it is hard to identify the individual factors that truly contribute to long term health.

However, sans some sort of manual on how the human body works, having a group of researches that have done the diligence of identifying the areas where people live the longest, healthiest lives, and extracting common elements, is extremely valuable. There will most likely be many parts of this book that will be disproved, but there is a lot of empirical evidence that these behaviors and practices will lead to a prolonged life with a higher quality of life.

From Emacs to Atom

I want to start this post by stating I have nothing but respect, admiration, and love for the Emacs community. Emacs’ extensibility, community packages, and it’s choice to effectively be an editor built on a lisp VM is amazing, and anyone choosing Emacs as an editor is investing in something that can grow with your needs.

Nevertheless, there are compelling reasons to switch to Atom. I am saying goodbye to Emacs, and have started using Atom as my main text editor.

My History with Emacs

I learned about Emacs during my college years (roughly 2008), when I happened to attend a house party for a family friend. The friend was a software developer who retired many years ago, but upon learning of my interest in software, he began to regale me with story after story of how much he does in Emacs.

“I check my e-mail with Emacs.”

“I built a program that opens my garage door from Emacs.”

“I share the same editor across multiple computers using the remote Emacs client.”

In all honesty I wasn’t really impressed by the idea of a program that you use to literally do everything, but it seemed like a great kernel for a text editor. I was using vim at the time and what I always lamented at (which I know others would say it’s vim’s greatest strength) was the fact that it could only be used to modify text. When I write code, I do so much more than write the code itself. I wanted an environment that made executing additional tasks seamless:

  • Interact with version control (git push / pull, commit, add)
  • Code search
  • Running command line scripts
  • Running a REPL and unit tests

Thus I dove into Emacs. The built-in terminal emulator, the ability to build whole programs in a single .el file and load them up, adding significant functionality to the editor, meant a lot of my needs were met quickly, and without significant effort. This became even easier with the release of Emacs 24, which included a built-in library to retrieve and install third-party packages, reducing the need to copy and paste.

I continued pretty happily for several years. I made a couple videos showcasing my Emacs setup, published my dotfiles, and wrote some tutorials as well.

Enter Atom

In 2015, Atom was released. An editor that was inspired by the flexibility of Emacs, but was built on HTML5 technologies. Using web technologies to build out massive native applications is not an advantage in every respect, but there are strong wins in some important areas.

A Powerful UI Framework

HTML, CSS, and Javascript have all grown to support the needs of the massive range of uses that websites are now used for, and the result from tackling such a large breadth is a powerful, general system for laying out various windows, styling them appropriately. Combine that with highly optimized runtimes to render said windows (web browsers) and you have a system that is not just developer-friendly, but also user-friendly.

Large Pool of Experienced Developers

A large portion of software engineers are web developers, and thus work in web technologies. The ability to transfer even some of this expertise as one is extending their editor removes a large chunk of the learning curve.

Impressed, But Not Sold

Atom was conceptually the editor I always wanted: the power of Emacs, a flexible UI framework, and a core built on technologies that I knew well and could contribute to. If I was starting from scratch, I may have chosen Atom, even when it just came out of beta.

However, I wasn’t starting from scratch. There was years of expertise in elisp, finding the right packages, learning to use them, and familiarizing myself with keybindings and the Emacs way of doing things. It didn’t make sense to throw those out the window for a nascent editor.

The Catalyst: Atom IDE and Language Server Integration

Since Atom came out, there was another text editor that entered the scene: VSCode. Similar in design to Atom, VSCode took a more opinionated approach to how an editor should be organized, and what tools to use (in the vein of visual studio). The more open world of Atom wasn’t a first priority (for example, VSCode did not provide support for more than three text windows at a time until recently).

However, VSCode did directly lead to the creation of the language server protocol, which enables any text editor to take advantage of IDE-like features, as long as they build an interface to a JSON-RPC based API.

When Atom implemented it’s language client, it was impressive, and it made me want to try Atom. But making the switch would require me to port all of my existing tools to find equivalents, and most likely learn a new set of keybindings. I already had a lot of that in Emacs. However, there was a final factor that really made me switch.

Community Critical Mass

For almost any tool or program, you’ll find one that is better in almost every significant way, but yet has not taken off. As much as we’d like to believe software engineering is a purely merit-based field, the reality is it depends on socio-economic factors as much as every other discipline. Market and mind-share matters.

The most impressive part of the language server protocol is not that it was built, it’s who built it. Facebook was a major contributor, teaming up with Github to build a real IDE experience for Atom.

Facebook’s business practices aside, they have a giant and talented engineer base. With Facebook engineers supporting a plugin like the Atom IDE, there’s a strong chance that you will see that integration improved and supported for years to come. And Atom is also a blessed project from Github.

I love Emacs, but it’s primarily supported by a volunteer base, who have other fulltime jobs. It’s very difficult trying to get a group of developers to implement something like language server support, and maintain and contribute back for years to come.

And the active community is larger around Atom. As of October 2018, here’s the counts of packages on the major package repositories per editor:

Unfortunately, Emacs does not have the development community in the same way Atom and VSCode can. That’s a conversation worth diving into, but it doesn’t change the state of the world today.

Migrating to Atom

So, I migrated my Emacs setup to Atom. Since I was a relatively late adopter a majority of my desired features were already a part of the editor, or were available as an extension.

I don’t think it’s valuable to dive into exactly what my setup looks like, but if you’d like to learn more, you can check out an Atom plugin I’m working on:

https://atom.io/packages/chimera

I am not using Atom 100% of the time, and I haven’t opened Emacs in about a year. The migration process took a couple of weeks.

The Future

Today, I have a lot invested in Atom, and I like my experience. Language server integration was a missing pain point, and that ecosystem (along with Atom’s integrations with it) is getting better every day.

The biggest lost I faced with Atom was performance: due to its reliance on a browser-based renderer, performance suffers vs draw calls in a native GUI. There are also improvements that can be made to Atom to ensure more non-blocking UI actions.

The Atom team has been working on xray, a text editor designed for performance whose improvements will be incorporated into the editor.

VSCode has also been a lot better on the performance front than Atom (still orders of magnitude slower than native editors). I tried it out recently and found the performance gain for me has been imperceptible, so it’s probably not worth the effort to lose the extension and keybinding knowledge.

 

 

 

Some resources for XACT

XACT is a audio application used to manage audio for games using the XNA
framework. Here are some resources to help you get started.

Installing XNA 4.0

you may need Visual Studio 2010 express to use it:

Visual Studio 2010 install links

Make sure to install the C# express version.

After that, try following this tutorial to build XACT projects.

Slimy: another html5 slideshow

image0After seeing a coworker’s presentation completely done using
html5 and javascript, I really realized how much of a platform that
html5 can be. Effectively, it’s a ubiquitous platform by which any
operating system can run code, with very little prior setup necessary. I
really liked the concept of an html5 slideshow, so I looked around for
one that suited my needs. There wasn’t one, so I began to write my own.
I present Slimy:

http://code.google.com/p/slimy/

You can see an example here:

http://slimy.googlecode.com/git/example.html

I explored html5 slideshows quite a bit, and I had two main issues that
got me interested in writing my own:

  1. Every html5 slideshow I saw had online dependencies. I understand
    that the web is everywhere, but I still didn’t want to rule out
    situations where internet access is not readily available. Simply
    saving the slideshow locally with a browser was a viable option, but
    I preferred to also clutter my file system as little as possible.
  2. The markup wasn’t always straightforward. I was recommended both the
    google html slideshow and rubyforge’s slideshow, but I didn’t like
    the idea of having to learn a different proprietary markup,
    especially when html is about as simple as markup gets.
  3. The slideshows included little fixes to make up for css3 technologies
    that weren’t supported. I didn’t like this. I was looking for
    something that doesn’t sacrifice simplicity to try to make the code
    work for less standard-compliant or outdated browsers. My system
    works for the newest browsers, and I don’t imagine that changing.

Slimy focus’s on encapsulation of the slideshow, and also functionality.
My main goal is to make it as functional as Google’s html5 slideshow,
but much simpler and elegant. I aim to keep it that way by including as
few proprietary functionality as possible, instead relying on css3 and
javascript such as css transitions. I do require jquery, but I think it
makes the functional code significantly more elegant and readable.

I would love to see some feedback, and I am willing to add more
functionality as requests come in. So please, give slimy a shot! I have
a feeling you’ll rarely use Powerpoint or any other slideshow
application again.

Getting Python2.5 to Build with sqlite3 and zlib on Ubuntu Natty 2.5

I had a really hard time finding this, so I’m posting it here:

First one must install all the proper packages on Natty (these are the
packages needed for zlib and sqlite in general, not just specifically
for Python):

sudo apt-get install zlibc zlib1g zlib1g-devsudo apt-get install sqlite3-dev

Then one must add an LDFlag to the new lib directories (apparently Natty
has a new directory for X86_64 lib files):

after the ./configure open your Makefile and find the line withLDFLAGS =edit to LDFLAGS = -L/usr/lib//x86_64-linux-gnuand make

Credit for the above snippet goes to Awin Abi and source is below:

http://groups.google.com/group/google-appengine/browse_thread/thread/a8bd0a71270a3ce6

Basically, setting up Python2.5 ( and presumably any version of Python)
properly involves downloading the proper package libraries , then
building Python2.5 with those packages. In order to do this, the LDFlags
variable must have the new library location (the
/usr/lib/x86-64-linux-gnu) for Natty and 64-bit processors added.

I have not tried this on a 32-bit machine. This may not be required
then, or you may need to point the flag to load the proper directory.

My IDE in Emacs (mainly for Python)

I’m writing this article up to mainly keep track of the current state of
my IDE in Emacs, how to set one up, and to keep my to-do list.

Implemented Features

Default Emacs Library Includes

I use the following from the library that comes with Emacs (as of
version 23)

  • Viper-mode (viper-mode 3, though I’m sure 5 would be good too)
  • Windmove (through keybindings, for moving around windows easier)
  • hideshow (for code folding)
  • ibuffer (for listing on buffers when buffer switching)
  • ido (for listing of file in a directory in the minibuffer

Code to instantiate:

(setq viper-mode t)(require 'viper)(load-library "hideshow")(add-hook 'python-mode-hook 'hs-minor-mode)(require 'ido)(ido-mode 'both)

Keybindings

(global-set-key (kbd "C-x C-l") 'windmove-right)(global-set-key (kbd "C-x C-h") 'windmove-left)(global-set-key (kbd "C-x C-k") 'windmove-up)(global-set-key (kbd "C-x C-j") 'windmove-down)(global-set-key (kbd "C-x C-;") 'hippie-expand)(global-set-key (kbd "C-x C-g") 'find-name-dired)(global-set-key (kbd "C-c C-t") 'ansi-term)

Viper Keybindings (in .viper)

(setq viper-expert-level '3)(setq viper-inhibit-startup-message 't)(setq-default indent-tabs-mode nil) ; I think this makes tabs into spaces(setq viper-shift-width 4) ; don't touch or else...;; Makes searching w/ regex default(setq viper-re-search t) ; don't touch or else...;; The following is for hideshow to work ALMOST similar to vi folding;; (there were keybindings I didn't like)(define-key viper-vi-global-user-map "zt" 'hs-toggle-hiding)(define-key viper-vi-global-user-map "zM" 'hs-hide-all)(define-key viper-vi-global-user-map "zm" 'hs-hide-block)(define-key viper-vi-global-user-map "zR" 'hs-show-all)(define-key viper-vi-global-user-map "zr" 'hs-show-block)

Features implemented using external files

Yasnippet (for bundling and snippets)

Yasnippet provides me features along the lives of textmates bundling,
which I think definitely makes things faster in the long run. After all,
who wants to write boilerplate code?

http://manual.macromates.com/en/bundles

Yasnippet site:

http://code.google.com/p/yasnippet/

lusty-explorer.el (for a great tab completion file navigator)

Followed this emacs-fu guide:

http://emacs-fu.blogspot.com/2010/07/navigating-through-files-and-buffers.html

And downloaded the .el here:

http://www.emacswiki.org/emacs/LustyExplorer

Specifically I have the following in my .emacs:

(when (require 'lusty-explorer nil 'noerror)  ;; overrride the normal file-opening, buffer switching  (global-set-key (kbd "C-x C-f") 'lusty-file-explorer)  (global-set-key (kbd "C-x b")   'lusty-buffer-explorer))

Desired features

I have yet to implement this, but I would like:

  • Better file search (the ones I could find don’t do what I’m looking for)
    • Specifically, looking for a smart find that allow autocompletion
    • Looking for something along the lines of eclipse

Hello world!

Welcome to WordPress.com. After you read this, you should delete and write your own post, with a new title above. Or hit Add New on the left (of the admin dashboard) to start a fresh post.

Here are some suggestions for your first post.

  1. You can find new ideas for what to blog about by reading the Daily Post.
  2. Add PressThis to your browser. It creates a new blog post for you about any interesting  page you read on the web.
  3. Make some changes to this page, and then hit preview on the right. You can alway preview any post or edit you before you share it to the world.