Dharma Talks

Despite living in the heart of the Bible Belt, I’m not religious. But that doesn’t mean that I’m not curious. That I don’t believe that somewhere in the roots of religion and other forms of spirituality you can find something real, something that applies no matter the century.

I’m really enjoying learning about Buddhism. My curiosity was first sparked listening to Dan Benjamin on 5by5 podcasts Back to Work and Build and Analyze. Dan would regularly throw in small bits of Buddhism to other topics.

To add to that spark, the first time I visited my sister in San Francisco, she told me about Mission Dharma. Mission Dharma describes itself as a San Francisco sangha that has gathered in the Mission District for over 25 years. In the midst of the overwhelming experience that is that city, I didn’t absorb what she was saying.

Fortunately, my sister is a pusher. I can’t remember how many times it took, but she eventually got me to listen to one of Howie Cohn’s Dharma Talks on the website. The talk was great.

Unfortunately, the experience of listening to the talk wasn’t great. I listen to things like that on the way to work. The length of the talk doesn’t correspond perfectly to the length of my drive. And mobile Safari has a way of reloading tabs due to memory demands, which means that I would regularly lose my place in the middle of listening to a talk.

So I started making an app to solve those problems. This past December Mission Dharma gave me permission to put it on the iOS App Store.

You can find it here, for free. I hope you’ll try it out and get something meaningful from Mission Dharma’s Dharma Talks.

I have also made the source code free. Maybe you can use it for your organization. Most of it is generic, but the part that pulls the audio files from the web page is a little hairy.

If you are part of or know of an organization that is doing good in the world that could use an app like this, please reach out to me and hopefully I can help.

Write, Powered by Magneto

In my original post about Don Melton’s Magneto, I said that one of the disadvantages of using Magneto is that there was no good way to write a post on mobile devices. When I wrote that, I had every intention of building an iOS app to work with Magneto. I am proud to open source a beta version of that project today, which I am calling Write, Powered by Magneto in my typical pattern of naming things generically.

I am not planning to make any further commits to this project until iOS 7 is out to avoid releasing any code that is under NDA.

And yes, I know it’s ugly (especially on iOS 6.) Adding design, and hopefully a bit of delight, are next on my to do list.

Prerequisites

  • You must have your Magneto blog’s folders linked to Dropbox in some way, whether it be by symlinking Dropbox folders to your local directories or by storing all of your directory tree in Dropbox directly. Write uses Dropbox to keep all of the draft, post, images and video in sync and accessible on iOS.

  • You must have a Dropbox Core API key, which you can get from Dropbox.

  • You must have Xcode so that you can build the app

  • You will need to make your own “Credentials.h” file in your project. It will need to look something like this (or you can look at my commit history, because I accidentally committed it…whoops!):

      #ifndef Write_Credentials_h
      #define Write_Credentials_h
    
      #define CONSUMER_KEY @"your Dropbox key goes here"
      #define CONSUMER_SECRET @"your Dropbox secret goes here"
      #define USER_NAME_TOKEN @"choose a name for the oauth token to be saved in the keychain"
      #define USER_NAME_TOKEN_SECRET @"choose a name for the oauth token secret to be saved in the keychain"
      #define USER_NAME_USER_NAME @"choose a name for the user name to be saved in the keychain"
      #define SERVICE_NAME @"choose a service name under which to save the keychain information"
    
      #endif
    
  • As specified in the Dropbox Core API setup instructions, you will need to change this section of “Write-info.plist” to have your Dropbox key after the “db-“:

      <key>CFBundleURLTypes</key>
      <array>
          <dict>
              <key>CFBundleURLSchemes</key>
              <array>
                  <string>db-0bzv4hxmz3d1144</string>
              </array>
          </dict>
      </array> 
    

About Write, Powered by Magneto

While designing Write, I tried my best to keep true to the way that Don designed Magneto. To that end, Write is designed simply, with no underlying database. The app relies only on the file system in Dropbox and two preferences that are stored about your blogs: the location of the blogs in Dropbox and the index of the blog you are currently viewing.

This approach has at least one limitation that I have run into so far – since all of the information about your drafts and your posts is stored in memory, a large number of either could overwhelm the relatively small amount of memory available on your iOS device. I have done my best to keep that impact to a minimum.

My other major design goal was to enable the user to complete the entire drafting and posting process inside the app. That is another reason I created the html5video plugin for my daughter’s site - I can easily and directly take the video on the device and upload it to Dropbox. In this version, any cropping of videos or images must be done in the Photos app, but at least everything can be done on the phone.

Limitations

Since the iOS app is not actually putting the file on your server when you press the “Post” button, some other process must be running to do so. The two options that I know of to do that are to be running Magneto in auto mode on your Mac, or to be running Magneto in auto mode on your server, with the Dropbox files shared to your server.

Currently, I am doing neither of those – I am manually deploying to my server after posting in the iOS app.

Walkthrough

When you first open Write, after connecting to your Dropbox account, you will be shown a list of directories that might contain Magneto sites.

Blog choosing screen

Upon choosing the site or sites that you want to have available in Write, you are taken to a list of the sites you have selected. You can choose one to see the drafts and posts for that blog.

Available blogs

Once you have chosen the blog you want to see, you will be shown a list of the file names for your drafts on that blog. Using the segmented controller at the top, you can choose to see the ten most recent posts.

From this screen, you can choose a draft or post to see and edit the contents, or you can click on the “New Draft” button to create a new draft.

Drafts for my blog

The view of the draft is simply the content of the markdown file. As you can see in the screenshot, nothing is wysiwyg. It is the exact same thing you would see if you were editing the file in Sublime Text 2 on your Mac.

Editing a Draft

As you can see in this next screenshot, I haven’t put anything nice like a keyboard tray with common markdown keys in this version, but probably will in the future. You will also see a “Save” button. That button will upload the file to Dropbox, as will going back to the drafts screen. The file is automatically saved locally every five seconds. I have also included a button to add media, whether an image or a video. As I said before, this button will add the media to your Dropbox and place the proper tag at the cursor location in your file.

Editing a Draft with Keyboard

I think I am handling conflict resolution for the versions of files in a conservative manner. If the copy of the file on the local file system was modified after the copy on Dropbox, then Write updates the copy on Dropbox with the local copy. If the local file was modified before the Dropbox copy then Write creates a new “conflicted” version of the file.

From the draft editing screen, you can choose the “Post” button to move the file from the Drafts folder to the items/current year folder. Choosing that button will change the time stamp in the file to the current time and change the name of the file to the name on the title line, if they differ.

Conclusion

I hope you find Write useful.

If you would like to contact me for bug reporting or any other reason, I am on twitter @davidbrunow or you can email me at [email protected]

Wake Up to Music

You really should subscribe to Rdio. I cannot recommend the service enough, and I genuinely believe that it has made my life better.

But maybe you don’t subscribe to Rdio. Perhaps you already have a huge music collection and don’t like the new stuff that the kids these days are into. Or maybe you only listen to The Beatles and other artists whose music is owned by people who have an interest in holding back technology.

But obviously you really love Jenni Leder’s design of Wake Up, Powered by Rdio.

And since that’s the case, you will want our new app, Wake Up to Music. All the same functionality but powered by the music collection you have on your iPhone or iPod touch.

$1.99 in the App Store now.

Magneto Revisited

I recently created my second site with Magneto, so I’m going to share my experience in doing so.

Background

I have had a website for my daughter hosted on Squarespace for a little over a year. The initial concept for the site was a sort of picture based storybook, something that I could read to my daughter as a bedtime story perhaps. None of the templates on Squarespace did exactly what I wanted, so I got a close approximation of what I wanted by futzing around with javascript and CSS every time that I made a post.

All of that futzing meant that I only made about 3 posts, all very soon after I created the site. I attribute that lack of posting to two factors (and I like to believe that it isn’t because I’m a bad father):

  1. The time it took to make a post – to make the Squarespace site do what I wanted it to do, I had to spend about 20 to 30 minutes for each post. That was mostly because I would have to look at the past posts to re-learn what I had hacked together the previous time.
  2. Having to log in to Squarespace – I’ve found that having to log in to a service is a large enough hurdle to discourage me from using it. Any friction in the form of discouragement is a factor that will undermine my intentions and that I want to eliminate.

So I decided to abandon Squarespace and create another Magneto site.

Change of Plans

As I said earlier, I had an idea in my head of creating a website that was sort of like a children’s bedtime story book, to which I would add new information about my daughter as she grew up and could do more things. But I ran into problems with this concept. Where would a new user start in reading the story? If I put them at the beginning of the book then they would get the full effect of the story. However, my friends and family that checked back often would have to jump through hurdles to get to the new stuff. Additionally, in a children’s book there is generally one picture and caption per page. Having the same effect on the web would require a lot of clicking and waiting1, delivering a poor overall user experience.

So I abandoned the original idea and one of my primary reasons for leaving Squarespace2. The new concept reminds me of what you would see on many Tumblr sites, pictures or videos with some comments.

New Implementation

Setting up Magneto was very easy to do. I simply followed my instructions (having to fix a couple of typos along the way) and I had the basic site up in a few minutes. It is so much easier the second time around.

Despite changing my overall concept of the site, I still want to tell a story through the use of pictures and videos. In order to do that, I had to make some modifications to the stock Magneto setup.

First, I added some hacky javascript to the article template so that my pictures are in a separate div from the caption text. You can see that javascript in post_article.erb on GitHub. This allows me to show the caption text on top of the image when it is moused over, and let’s the images speak the rest of the time.

Next, I created an HTML5 plugin that I use instead of Don’s video plugin. As I learned after diving into this, HTML5 video is a bit of a pain in its current form, which I attribute to Firefox’s insistence on not supporting the H.264 format. The plugin that I created does not account for this issue and therefore the videos do not show up in Firefox (although I added more hacky javascript to allow them to be downloaded). Not supporting Firefox has given my father a reason to troll me, but I had to make a decision based upon my particular constraints, and one of those constraints is that I would like to be able to make the posts completely from the file system on my iOS devices. From my research, it isn’t super straightforward to export Ogg Vorbis from the iPhone and even if I did that, I would be using twice as much space to store each video, which is just a waste. I also want to have full control over my videos, and I don’t want to have to log into yet another web service. So for now, HTML5 with no Firefox support is the way I’m going.

Now a short bit about my experience serving images and videos. I have no prior experience in this area (my current professional work involves sites on an intranet that have little to no media assets) so I was experimenting with serving these assets straight from my server (which is the lowest tier virtual private server at Midas Green Tech). With this strategy, my server would become unresponsive shortly after uploading updates to the site. I believe that this is because the server was caching those assets in memory, but I am not completely sure. I next experimented with a CDN, Cloudflare to be exact, and the server’s unused memory went up dramatically and load times shortened dramatically. In other words, as convention would tell you, use a CDN.

The last thing that I modified was Don’s timeago.coffee. I wanted the time stamps on my daughter’s site to display my daughter’s age at the time of the posting, so I created timesince.coffee. You can provide the script a starting date and it will display how long after the date that that post occurred, with accuracy to a month.

Conclusion

I am quite pleased with my switch to Magneto for my daughter’s site. I have already posted more times than I did on the previous platform, and more importantly I don’t get that feeling of dread that I usually do when I have to put in a password and navigate a site that I’m not used to navigating. I can almost do everything on my iPhone.

Would I recommend this setup to someone who is not technically minded? Definitely not. But if you are already managing a Linux server and want to share some pictures and memories with family and friends, or just want to have a memory for yourself, I think this is a great way to go. I might just be putting together another soon, and I will definitely be iterating upon my daughter’s site in order to get it closer to my original concept.

You can follow me on Twitter @davidbrunow where I will post links to any further blog posts about my experience with Magneto. And as a reminder, Magneto was created and open sourced by @donmelton.

  1. I could make the waiting after clicking much shorter by fully loading all of the content at the beginning, and then using JavaScript to hide and show different “pages”, but that would add more complexity to the site and make the template system generated by Magneto more difficult to use. Scrolling is very natural on the web, and probably the best way to do it.

  2. I do not regret my decision to stop using Squarespace, because of the following benefits of self hosting: 1) I have the content on my local machine and can use it any way that I like, 2) I don’t have to log in, and 3) I can run my daughter’s site on the same server that I run my own which saves me money.

She’s Seizing

Last Thursday night I didn’t sleep well. My heart was racing and I was restless most of the night. Then I felt “off” all day Friday. Didn’t know why.

On the way to pick up my daughter from my ex-wife’s house I was anxious and uncomfortable. For no known reason I had a feeling something bad would happen soon.

I’d been driving for about 15 minutes with my daughter in her carseat in the back. She made a coughing/gagging sound and I looked back at her. She looked like she was spitting up some mucous. Her body was limp against the straps of the seat. I sing-songed “Emma” with no response. I started saying the ABCs, one of her favorite things to say back to me. Still no response, only more gagging, more spit up.

I frantically found a place to pull over, put on the hazards, and got her out of the car. She slumped over on me and continued to cough and gag every few moments, spitting up on both of us. I held here there on the side of the road, hoping I could help her get out whatever was causing her sickness. Nothing more than that mucousy substance came out. She barely had the energy to contract her stomach to cough.

After a few minutes, I gave up on the idea of her coughing up whatever was bothering her and got her back in the car. It was only five minutes back home so I decided it would be better to get her comfortable and laying down there. I called her mother to see if she had been acting strangly at all that day – no, she’d been acting normally.

I laid her down on the floor of my apartment, took off her clothes that she’d spit up on, and tried to comfort her. Her face was pale white and her lips had little color. She was breathing erratically. I was flipping out on the inside but tried to stay calm on the outside.

Finally, she spit up more than just mucous. Finally, she started looking better. I sat down next to her and she looked up at me. She was more responsive than she had been since she started gagging in the car.

Then her left arm started moving rhythmically. Up and down, up and down, up and down. I didn’t want to believe that something was wrong – I wanted to believe that she was comforting herself through that rhythmic movement. Then her eyebrows started moving up and down, then her leg, then her tongue. I got her in the car to head to the ER.

The drive to the ER felt like forever. Emma was limp in the backseat, her body moving beyond her control. When looking back at her at a light, I’d picture her smiling during bathtime – laying her back in the bathtub, with her hair floating above her head in the water. Then a snapshot of the enthusiasm with which she would look at me when I would start saying the ABCs came to the forefront. I almost lost it a few times. But I told myself “now is not the time for that.”

I get her to the ER, out of the car as she slumps over, still rhythmically moving. They take her to the back, put her on a table and start stabilizing her. An insensitive tech is suddenly standing next to me and states “She’s seizing?” I don’t know what to say. “That’s what they’re saying” is what I come up with. My daughter is having a seizure. I almost lose it again. I almost lose it so many other times in that ER as the techs, nurses, and doctor work to stabilize her. They do.

Emma was taken to a Children’s hospital and spent the next day there. Through the haze of anti-seizure and anti-fever medication, my daughter started to come back. She talked a little. She drank some milk. She smiled.

Emma is back to her normal self now. Her EEG showed that she had abnormal activity on the right side of her brain. We have no idea why the seizure happened or if anything triggered it, but the abnormal activity means that she’s more prone to future seizures than the average child. She’ll be taking anti-seizure medication twice a day for who knows how long. And like with everything else Emma has gone through, we’ll see how this all turns out down the road. It’s just one more unknown.

Emma in the ER

Minimal to a Fault

Jenni and I intentionally shipped an app with a fatal flaw.

No, I don’t mean the inability to change am/pm manually.

iOS, the operating system that runs on iPhones and iPads and iPod Touches, will not allow our app to do what it needs to do if it isn’t running. That means we can’t let the phone go to sleep and then have the app automatically open when it is time for the alarm to go off. That means that you have to open the app to set the alarm every night (or morning) before you fall asleep.

I knew about this fatal flaw when I started development on this app a little more than a year ago.1 I did research into different hacks that could possibly be used to allow the app to function in the background. At one point, I had decided not to make it at all since I couldn’t make it work perfectly. That’s what Apple does, right? They wait for the technology to mature before creating something half-baked? Well, I really wanted it to exist, so I built it anyway.

Fully knowing the burden of the flaw2, I made choices to allow setting your alarm every night to be as simple as possible. I added the ability for the alarm to start automatically at launch, so you only have to tap the icon to set the alarm. I designed the time input so that you can directly choose the numbers for the time you want to wake up, instead of scrolling back and forth in a picker like in a typical alarm app. And you don’t have to choose am or pm, because the app picks the next occurrence within 12 hours. With this design, choosing 6:30 am takes 3 taps.

I’ve used this app almost every night for the past year. I am constantly thinking of things that would make my process of going to bed and waking up better and adding those ideas to the app. I hope they make your nights and mornings a little better too.

I hope you enjoy our imperfect app.

  1. I’ve used a handful of different iPhone alarm clocks over the years, but I never stuck with them because of the friction involved with setting the alarm every night.

  2. I stopped using this feature after Jenni’s beautiful redesign of the app. Now I actually want to experience the UI, rather than skip it.

Daddy Daughter Time

Tonight as I was feeding my daughter, she reached out her arms towards me and I leaned forward.

She grabbed the sides of my face and moved my head towards her right side.

She paused and looked at me.

She moved my head towards her left side. And paused again, looking again.

Then she pushed my face away, and softly, with a tiny smile, ‘cough cough’.

A huge smile spread over my face and my heart melted.

I’m ‘cough cough’. She knows me.

Where I Work

My Rad Desk

This is where I’m working right now.

I took the top from my cheap, particle board with dark wood veneer breakfast table, which I bought from Walmart about a year ago, and cut it in half. Surprisingly, the veneer didn’t peel back – the Internet’s advice to cover the cut line with blue painter’s tape actually worked. Unfortunately, I didn’t have my saw configured correctly from the start, and the cut isn’t straight.

After cutting the tabletop in half, I placed it on a couple of the chairs from the table. Voila, desk.

Really, it’s a pretty bad solution at this point. My knees hit unless I slide my feet to the extremes of my range of motion, carefully maneuvering around the chair legs. My elbows drop below my wrists and in the lightly padded folding chair, I crumple over most of the day.

Anyhow, you don’t get to make excuses about a comfortable chair or proper ergonomic position holding you back from creating things. Set up a desk, follow my recommendation, and start sharing with the world!

Magneto

As I state on my ‘about’ page, I am using a static blogging engine created and open sourced by Don Melton to create this site. I’ll to talk through why I chose Magneto, the current limitations of my setup, and walk through simple tutorial for other ruby amateurs that may want to set up their own Magneto site.

The main reason that I want to use a static blogging engine is that I want to have complete control over my content. With Magneto, every part of my website is generated on my local computer. If the company that I rent a server from goes belly up, or the hardware server on which I have one small, virtualized chunk gets seized by the government, I could be back up and running on a new server with a different company before the DNS records could change.

Since I have complete control over the content, that also means that I can change the CSS and JavaScript directly. When using a drag and drop type tool that someone else created, I feel like I have to think through someone else’s mind. I don’t know their mental model for the task I am doing, so I have to figure it out before actually getting anything done. With Magneto, I just have to be able to read source code and think like me, and I’ve gotten good at the latter.

So why Magneto in particular? It is written in ruby and I was exposed to it through Don’s blog at the right time. If I had wanted to learn php, I would have started using Marco Arment’s Second Crack long ago.

Limitations

Currently, I have run into only one significant limitation with Magneto. I am certain that I can build a workaround, but I haven’t thought about it too much yet.

Doing anything with my website while on the go, other than edits to content, is more difficult than I would like. And even edits require that my computer is on, connected to the internet, and watching my local directory for changes. None of those can be counted on to be true for a laptop.

Getting Started with Magneto

These instructions are based on my experience installing Magneto on my 2012 MacBoook Air running Mountain Lion. But I did it a little while back, so if you run into problems, talk to me on twitter @davidbrunow.

Getting your site up and running with some custom design settings shouldn’t take more than a couple of hours, less if you know exactly what you want everything to look like.

Prerequisites

  • Web server - could be any variety since you will be sending it static files. However, if you are running a Windows or other non-*nix based server you will at least have to come up with a different solution to deploying your files than I will discuss here.
  • I will not cover the setup of this server here – I found all of the reference materials at linode very helpful if you are running a *nix based server.
  • *nix based local system (Mac OS X, Linux, Unix)
  • You must have ruby installed locally. If you don’t have it installed, follow these instructions.
  • You will also need coffeescript, kramdown, directory watcher, multi json, exec js and SASS installed locally.
  • You will need to be able to use a text editor (I use TextMate 2 because I want to be like the cool kids) and the command line.

Installing Magneto

First, let’s check to make sure that you have the prerequisite gems installed. Navigate to this directory either in Terminal or Finder (if you have a version of ruby other than 1.8 installed, then the path will be slightly different):

/Library/Ruby/Gems/1.8/gems/

Look at the contents of that directory, and see if the following directories exist:

coffee-script-2.2.0
kramdown-0.14.1
sass-3.2.5
directory_watcher-1.4.1
execjs-1.4.0
multi_json-1.5.0

If any of them are missing, run the following applicable commands to install them (since you are using the sudo command, you will have to enter your password after the first command):

sudo gem install coffee-script
sudo gem install kramdown
sudo gem install sass
sudo gem install directory_watcher
sudo gem install execjs
sudo gem install multi_json

Magneto’s installation is just as simple as the other gems. You just need to run this command on your local machine:

sudo gem install magneto

That was easy, wasn’t it? Now let’s put some content out there.

Website Generation Files

Now, you will need to create the files that Magneto uses to create your website. The simplest way to start is to download all of the files from Don Melton’s website from github and then put them in a directory. I created a directory called ‘brunow.org’ off of my home folder. I think that something off of your home folder will be simplest, since you can use ‘~/’ when needing to provide absolute paths.

I started by trying to download as few files as possible. The upside of this approach is that I was able to see what each file did by seeing which features were missing at each step. The downside is that it took longer and ground my teeth a lot. But since I already did that for you, I will describe each of the files that you need and what they do, grouped by directory.

~/brunow.org/

The files in this directory handle the basic scripting of building the website as well as the overall configuration:

Rakefile: this is ruby’s version of a makefile. In general, it is a script that performs certain tasks. In this case, it will start a new draft post, deploy files to your server, clean up folders and post a draft. You will need to make changes to this file, which I will describe later.
config.yaml: this is a general configuration file for your website. You will need to change a number of values in here, which I will describe later.
script.rb: I’m not sure of the most correct way to describe this file. Pretty much, it is the main source code file for the website. Magneto will read through this file, and generate posts based upon the files in the /Items path. This is the main component that uses all of the other ruby files to put all of the pages together.

~/brunow.org/Items

The files in this directory are either a template of each file that will be moved to the server for the website (about.md will become /about/index.html) or the file itself (/favicon.ico will become /favicon.ico in the output.) All content, such as the ‘About’ page and each individual blog post, is in a variety of Markdown format called kramdown and when run through Magneto will be moved into its own directory and named index.html. Anything that will be generated by Magneto is in a file with a .erb extension.

.htaccess: this is a file that lives on web servers to establish access rights to directories.
404.md: this is the content that will be displayed when a page cannot be found on your server. It doesn’t follow the rule about being moved into a folder and renamed index.html.
about.md: this is content about you. Well, when you first download it, it is content about Don. So you will want to make it about you.
archives.erb: this is the template for the archives page of the website. This file contains both HTML and ruby. The ruby is used to group your posts by dates and display links to each of them in one location.
favicon.ico: this is the image that will show up in the browser bar when someone visits your website. You will need to provide and image and then you can follow [John Gruber’s instructions on how to make a retina favicon].
index.erb: this is the template for every file that will be an index.html, which is based upon the document.erb template.
robots.txt.erb: this is the template for the file that tells the ethical bots whether they can traverse your site
rss.xml.erb: this is the template for your RSS feed.
sitemap.xml.erb: this is the template for your site map.
css/style.sass: this is the stylesheet for your website, in [SASS] format. It will become /css/style.css after processing through Magneto (which handles running it through the SASS engine for you).
includes/sidebar.erb: the includes folder holds different ‘components’ of the web page. This particular file the is template for a right sidebar that has a short bio, recent articles and search.
js/jquery.min.js: the jQuery JavaScript library is an easier way to do JavaScript - it contains advanced functions that would be a pain to write yourself, and solves browser compatibility problems.
js/timeago.coffee: this coffeescript changes the date at the end of your posts from ‘January 3rd, 2013’ to ‘Two months ago.’

~/brunow.org/plugins

The files in this directory are called by either the script.rb file or by the .erb files that build the pages. Each performs its own little part in the process of website generation, and has documentation at the beginning which I will pretty much restate here:

copyright_year.rb: uses the copyright year information in your config.yaml file to determine how to display the copyright years
image.rb: creates proper image tags
items.rb: parses individual markdown files to create posts
markdown_inline.rb: parses the markdown syntax
reduce_empty_lines_filter.rb: removes extra whitespace
relative_to_absolute_urls_filter.rb: changes relative URLs to absolute
remove_more_marker_filter.rb: gets rid of the MORE marker
strip_html.rb: not sure
symbolic_to_numeric_entities_filter.rb: changes symbols like &amp; to their numeric equivalent &#38;
video.rb: creates the proper video tags

~/brunow.org/templates

document.erb: the basic template of each ‘index.html’ file that will be created by Magneto. You will need to make changes in this file
page.erb: the template of the page that is inside of the document
post.erb: the template for each post that will be on the main site page
post_article.erb: the template of the page if it is an individual post, rather than all posts

Customizing Magneto

Now I will describe the small number of items that you absolutely need to modify to get Magneto running as well as those that you will need to change so that you are not copying the style of Don’s site.

First, open config.yaml in your favorite text editor. Change base_url: to be the name of your site. If you know how your CDN works, then put in the proper URL there for cdn_url: – I think mine is the same as my base URL, but I haven’t researched that yet. Change the copyright information to yours, and put in a description of your site. This description will be part of the document header if you use a template similar to Don’s. If you are going to be using Google Analytics, then change Don’s number to yours. I actually left Don’s GA number in there because I am not using GA and I got an error when running Magneto when I took out that line completely. I did remove all of the GA JavaScript from the pages, however, and will try to track down the source of the problem with removing that line in the future. Instead of GA, I am using Mint. Why did I choose Mint? Because I want to own my analytics, just like I want to own everything else.

Anyhow, back to changing the config.yaml file: change search_sites: to your site’s URL, change the title: to whatever you want to show up in the browser’s tab bar, and change visible_posts: to show the number of posts that you want on your main and subsequent pages.

Now to the Rakefile. I don’t use the ‘stage’ or ‘deploy’ sections of the Rakefile right now, so I won’t speak to them. The one thing you need to change if you are going to be using the Rakefile for deployments is the part after rsync. You will need to put the information for the directory that you have your output folder in as the first argument after -avz. I use the absolute path because I have another process that calls Rakefile to make things more automatic. You will then need to put in the information for your server as the last parameter.

Ok, now to the customization of the look of the site. Let’s start in templates/document.erb. In here, you can change the names of the items in the header, add an image to your header like I have, or do other structural type tweaks. This is stuff that I can’t tell you what to do – it is time to make it yours.

So next, we will head to another area that I can’t tell you what to do: the css. I change a few things in items/css/style.sass, such as the color of the footer, the way that the site handles different screen widths, and hiding the sidebar.

Ok, you are just about ready, you just need to do three final things:

  • Delete the directories for each year (2012, 2013, etc.) These contain Don’s blog posts, which you won’t need.
  • Edit ‘about.md’ so that it contains information about you instead of information about Don.
  • Replace favicon.ico with an icon of your choosing. Don’s face won’t represent you very well.

Workflow

My workflow is constantly evolving and hopefully I can keep updating it here as I learn to use Magneto in ways that will better suit my needs. Like the furniture in my living room, I constantly tweak my workflow to try to make myself more comfortable and reduce friction – anything that I can do to make myself write more often is a good thing.

That being said, here is my current process:

I start a draft post with the command rake draft. This way, a new file is automatically created in the drafts directory with a current timestamp and a title that I provide. Since I have my entire ~/brunow.org folder symlinked to my dropbox account, I can then either edit the file in TextMate 2 locally, or use IA Writer on my iPhone or iPad. Sometimes though, I bypass all of that and just start typing in my Notes app on my phone. Then I can just do a copy and paste from my Notes app on my Mac into TextMate when I am ready to create the post. Realistically, the limitation of having to make posts on my computer isn’t a bad thing. It means that I have a higher likelihood of taking my time to develop my thoughts, helped by using a screen that is large enough to see meaningful amounts of text at the same time, which I find is better for editing and pruning my ideas.

So that I can make edits to existing files from anywhere, I have Magneto running in auto mode on my MacBook Air. When Magneto detects a file that has changed in the /items path, it will regenerate the site. I then have folder actions setup on the ~/brunow.org file. I learned about how to set up the folder actions on this site. That action calls a script, which deploys the files to my web server with the command rake deploy and then runs the command rake clean which removes the output directory and all of its contents. As discussed earlier, rake deploy uses rsync to send your files to the server.

Since I am using the auto mode of Magneto I could technically start a new post on my phone, but I really like how it automatically handles the timestamp for me instead of my having to figure out the format once again and then typing the whole thing.

Once I have finished writing the post, I use the command rake post which re-timestamps, renames, and moves the files to the proper location for the site. Since I have Magneto running in auto mode, it rebuilds the site, and within about 30 seconds I get a Notification Center message that my files have been uploaded by my folder action.

Future

I hope to keep updating this as I get responses from other users, or as Don updates Magneto. A little down the road I hope to work on my fork of Magneto and my website and get them both up on Github so I can share any enhancements that I make.

I also am planning on using Magneto to create a static engine that creates a sort of “storybook”. But that is still just tumbling around in my head right now.

You should definitely follow Don Melton on twitter – he has already tweeted about one blog post about how to increase Magneto’s efficiency and he has great stories about his years developing Safari at Apple. Plus he just seems like a nice guy.

You should also follow me on twitter for none of the same reasons.

Maintenance Mode

When I published the first version of Wake Up, Powered by Rdio®, I had never been employed as a software developer. I had never read a book or taken a course in Objective C. I just wanted to wake up to music and my music was on Rdio. The app was a side project and a learning experience and I was proud of what I had accomplished.

Looking back, it was an amateur effort. It’s obvious now. But although it was imperfect, it was mine.

And it was a tool that I used every night and it worked. At least 95% of the time I was woken up to music. I have never made any money with this app, and I don’t expect to make any in the future. I couldn’t justify spending more time on it. And since I was so close to it, since I had designed and developed the entire thing, I really couldn’t see it being anything else than it already was. Four or five months ago I had decided that the app would be in ‘maintenance mode’ and that I wouldn’t do anything new to it.

Then I got an email from Jenni. Subject line: ‘Love your app’. That sure made me smile. She wanted to know if I’d be interested in her help with some UI work. I was skeptical. Visited her website – wait, she does this for a living? And she’s actually good? I was more skeptical. Plus, I didn’t know if I wanted to put any effort into the app. Worse, I didn’t know if I wanted to work with someone else. I struggled with the idea that someone else could do something better than I could, and that instead of this being my app, it would be our app. It sounds silly to write about now, but I was in emotional turmoil. I can’t say I got past that turmoil quickly, but I decided to at least hear her out. Turns out, she also lives in North Texas. So we met for coffee.

Coffee went well. Actually, coffee went great – I was energized by just starting to work with someone else that is passionate about what she does. We seemed to have similar tastes in design and left the conversation with the idea that she would create a mockup and I could decide to go forward with it at that point. I drove home a little giddy.

About a month later, she sent a mockup. I really liked the design direction, but I wasn’t sold. I was still wrestling with my control issues.

But I like to think of myself as someone who won’t miss an opportunity because of my own insecurities, so I decided to go for it. And for the past two and a half months Jenni and I have been crafting Version 2.0.0 in our spare time – working together to make something better than I could make alone. Jenni is a joy to work with.

This morning, I submitted to the App Store.

As I said before, my first attempt at this app was not a professional work.

But this one is. This one is beautiful and functional and polished and I am proud to say that I took part in bringing it into the world. I can’t wait to share it with everyone.

Version 2.0.0