chris barr

Photo/Dev/Design

A New Life in Georgia & a Wedding Website

Life Update
In less than a month now I’ll be getting married – it almost seems surreal.  I’ve been looking forward to this for a long time, mostly since I proposed to Kirstin about a year ago, but it’s so close I can hardly believe it.  I’ve lived in pensacola, Florida for the past 5+ years and Kirstin has lived Rome, Georgia for a little over 4 years now.  We had a long distance relationship for the entirety of our 2 years of dating, but in the past few weeks I’ve actually taken the plunge and moved up to Georgia.  We figured it was probably a good idea to at least live in the same state if we were going to be getting married.

It all actually worked out quite well.  The company I work for, AppRiver, recently opened an office in Midtown Atlanta.  The office is about 1.5 hours from where Kirstin works in Rome, so we decided to live somewhere in the middle and then we each commute to our workplaces.  The drives are fairly long, but  we think it’s worth it because we finally get to see each other on a regular basis and we both get to keep the jobs we love.

A Wedding Website!

chrisandkirstin

Soon after we were engaged, the wedding planning began.  One task on the list was to get a wedding website.  I thought “I got this!” since I do something similar for a living, so I made one.  I might have gone a bit overboard with the site, but it covers 100% of our needs, we love it, and we’ve gotten nothing but compliments about it.  I’ve made it in a fairly modular way, so I hope that others might be able to make use of it as well.  I’ve decided to put all the code on GitHub because… well why not.

Check out the site: http://ChrisAndKirstin.com
Get the code: https://github.com/chrismbarr/Wedding-Website

 

Lyric Converter V2!

If you just want to go use it: LyricConverter.com

But first…

The Backstory…

A few years ago my church used some lyric presentation software called SongShowPlus, and it worked… but we didn’t love it.  It only ran on Windows, it had some UI issues that made it hard to use and add/change songs before services. We wanted to get a Mac and run ProPresenter instead.  Friends in the same industry were telling us how they had switched and how much they loved it.  ProPresenter had a lot going for it, especially in the ease-of-use department and scalability for things we wanted to do in the future.

We were hesitant to make the change because there was no way to move all of our song files over. Neither program had a decent way to import or export song files, and there was certainly no way to convert between formats. A good friend of mine at a different church told me they were in the same position; they wanted to move from SongShowPlus to ProPresenter but they were holding off due to the inability to convert their songs. Honestly  I’m still surprised that to this day neither program provides a standard import/export for other file types.

The day finally came when our Windows machine died. We either had to buy a new one, or just go ahead and get a Mac with ProPresenter. We chose the latter option and manually converted the few songs we needed each week, or just downloaded them from a service called SongSelect. In the end this process wasn’t the best, but we got through it.  However, everything would have been much easier and less intimidating if there was just a simple way to import and export songs.

Version 1

This is the point when I decided to take a crack at it. I put our entire SongShowPlus library on my thumb drive and opened up the files in a text editor to see if it would be possible to get the text out.  The SongShowPlus file format is crazy, it appears to be a binary file with lots and lots of invisible control characters, but there is plain readable lyrics in there as well. Overall it seemed possible. Ok, so what about ProPresenter? Luckily the ProPresenter file format is a nicely formatted XML data, very easy to read and write from.  No problem!

At the time I was pretty comfortable programming in PHP, and I knew it’s file read/write capabilities so I decided to start there. I wrote a few complicated regular expressions to get the raw lyrics into an array, and it pretty much worked for most song files (with some tweaking)! This process took quite a while to get right because understanding the SongSHowPlus file format was fairly difficult. After that it wasn’t too much work to get it to generate the proper XML needed for a ProPresenter file. All that needed to be made now was a web UI for people to upload and download the songs! I put something together and I was pretty happy with it, and a few people used it. Yay! I even found out that the support staff at Renewed Vision (the company that makes ProPresenter) was actually recommending my site to customers making the switch, and that was pretty exciting news!

Oh and the name, LyricConverter… it just seemed obvious. (Also the domain was available.)

Problems

While what I wrote worked, it was a bit of a pain to use. If someone tried to upload too many songs at once the website would choke due to PHP’s upload file-size limit. Sure I could increase that, but someone could always upload more.  To solve this I had to impose restrictions of no more than 30 files at a time. This solved the problem, but if you had several hundred files to convert you were going to be here all day.

Another big problem was downloading the converted files. Each file was converted individually and stored on my server, but that meant after conversion you had to click on each file to download it.  So again, if you had several hundred files you were going to be here all day. That combined with the upload limit of 30 made this quite a pain to use. My eventual goal was to be able to have it produce a single .zip file with all the converted files in it, but that seemed a daunting task for PHP at the time.

One more problem I had, that was compounded by the above problems, was the amount of disk space and bandwidth used up on my server each month! I wrote a cron job that should have run once a day and deleted any files left on the server that were more than 12 hours old, but I found out that this did not run reliably on schedule and I often had to trigger it manually after I would get a “disk space exceeded” email form my hosting company. I also kept having to increase my monthly bandwidth because I was getting “bandwidth limit exceeded” emails. It was not uncommon for the site to blow through 1 or 2 Gigs of bandwidth in a month… and that’s for text files! (Although, it was a few hundred of them all transferred up once and then again back down)

Version 2

In my day job I’m a front-end web developer/designer, so I try to keep up with what the current browser technology supports and I’m quite honestly stunned at how many amazing things can be done all in the browser now.  Once I learned that there was a way to generate files in-browser with JavaScript to save to your desktop, I began to think about how re-writing LyricConverter could be a 100% in-browser process would solve all of the current problems I had.

Reading files dragged onto the browser was no problem, I was already doing that in the previous version.  Now I just had to take some of the regular expressions I had written in PHP and re-use or find a better way to achieve the same outcome in JavaScript. After some trial and error, I finally got this working how I wanted.  It will read SongShowPlus files and ProPresenter files, the output from either of those can be made to display in-browser as slides, convert to plain text files, or convert to ProPresenter files. Yes, you can convert ProPresenter files to ProPresenter files. Why? Well, why not. I doubt this is needed, but this does prove how flexible it is.

Since this is all in-browser there are no more “upload” limits, and there are no bandwidth restrictions. The only bandwidth used is just initially serving the page up to the browser. In fact since it’s all JavaScript now, it’s just being hosted on GitHub for free and none of my server resources are even needed any more.

Since files could be auto-downloaded (thanks to a library called FileSaver.js), that was great and it solved a huge problem of having to click individual links. A user could drag 1000 files into the browser, and then immediately click a button to download 1000 converted files… that is if you want 1000 files on your desktop… hmmm, that’s not appealing.  After some quick searching around I was amazed to find that someone has written a JavaScript library called jsZip that can actually generate .zip files with JavaScript! This was my ultimate goal, and it was to each to achieve with this library. Now when you convert songs you have the option to download all N number of files individually, or just download a .zip file containing them all.

I’m also extremely happy with how the code is structured now. Previously it was a huge mess and half of that was due to my unfamiliarity with PHP. Now it’s all written in JavaScript and it’s very modular. It should be easy to add on new file types that it could read from or output to.  It’s also all on GitHub, so anyone can feel free to improve the existing code or add new functionality like new input/output formats!

Use It & Improve It!

Like I said, all the code is on GitHub and I would just absolutely love it if people would contribute to this project to make it better.  Right now it works, but it certainly could be made better.  Occasionally I do get some strange conversion errors or random incorrect characters that slip through into the converted files.  I’d love to squash these bugs, but they aren’t deal-breakers at the moment.

So, please use it, let me know how it could be made better, and please contribute if you can.

What Do JavaScript And The Mission Field Have In Common?

On one side we have the web programming language JavaScript, and on the other we have Christian missionaries sharing the message of Christ with people all over the world. Where do these two unrelated things meet?

This week my church in Pensacola, FL is having a mission conference where we invite some of the missionaries we sponsor from all around the globe and put an emphasis on the important work they do. Several weeks ago I was asked if it would be difficult to make a counter that would show that on average 75 people die every minute without ever hearing the Gospel of Christ.  This didn’t seem like a terribly hard task, and it really helps drive home an important point.  If you’re curious, the number 75 was determined to be somewhat of an average rate per minute.  This Site says 103/minute, while this one says a little under 50/minute;  75 seemed like a good compromise.

Marcus Point Baptist Church - Missions Conference StageAt my church we have three 720p displays normally all driven by the same computer, but we also have the ability to change the input source of the center screen.  The counter I needed to make was to be the source of the center screen run from a laptop, but it needed to look seamless.  I was provided the appropriate background image, so now it’s just all about displaying a number on top of the background.

The core of how this works is extremely simple, but I wanted to make sure that it was flexible enough for anything we might need. I’ve worked behind the scenes in churches for years now and I know that really anything could pop up. The number “75” might need to be different at the last minute, the computer might crash or someone might close the browser and we need to re-start the count at a higher number, we might need a delay before the counter starts so we have enough time to switch the screen to it without anyone seeing the page refresh.

There are a lot of possibilities, but in reality we didn’t need any of these edge-case scenarios that I coded for, but I’m glad they were there “just in case.”

 

Here’s the ultra-basic code. It’s really nothing too special, but it gets the job done by incrementing a number at an interval determined by the rate.

(function(){
  //Numbers
  var num = 0;
  var perMinute = 75;
  var perSecond = perMinute / 60;
  
  //Element selection
  var count = document.getElementById("count");
  
  function update(){
  
    //Add the per-second value to the total
    num += Math.round(perSecond);
  
    //Display the count rounded without a decimal
    count.innerHTML = num;
  }
  
  //Run the update function once every second
  setInterval(update, 1000/perSecond);
})();

The full version has a bit more complexity to it because I built in a UI that allowed us to change the rate, change the beginning number, and add a delay before beginning the count. It also will attempt to use the Full Screen API that newer versions on Webkit and Mozilla browsers have implemented.

Be sure to read all the “gotchas” on the readme.md file on GitHub linked below if you view the demo, but basically your mouse cursor will be hidden until it goes over the controls which are hidden at the bottom of the page.

Check out the full code on GitHub or view a live demo!

Scrolling a overflow:auto; element on a touch screen device

UPDATE: this code may no longer be needed! You may want to use the CSS property -webkit-overflow-scrolling: touch instead. More details can be found on this StackOverflow post.


In mobile Safari on the iPhone, iPod Touch, and iPad (as well as the webkit based browser on Android phones) it’s not immediately obvious how to scroll a div that has overflow:auto; set on it. If this were a desktop browser you would see scrollbars and be able to manipulate those or even use your mouse wheel. No such concepts exist on a touch screen device!

To scroll the entire page you just touch it and move your finger. But when you touch the element that would normally scroll, the entire page scrolls instead. This is a little bit broken in my opinion since there’s no visual indicator that you aren’t seeing all the content. However, if you are on a site and you know there’s a scrollable div there is a simple (but not obvious) workaround. Simple use two fingers at the same time and scroll them in the same direction.

This works OK but like I said it’s not obvious, there’s still no indicator that the content is scrollable, and when you use more than one finger you might accidentally trigger some other gesture like scaling the page. I recently ran into this exact issue at work and came up with a pretty solid solution in javascript. I broke this down into two simple functions, but the last one is where the magic happens.

This first function simply attempts to create a new touch event. Only touch screen browsers like mobile Safari have these events, so if it doesn’t throw an error then we are using a touch screen device. Otherwise it’s probably a desktop browser.

 

Next, this function calls the isTouchDevice() function, and if it succeeds we attach some special touch events to the page. First when a touch event begins (the touchstart event) we get the current scroll position and prevent the default browser behavior, which in this case would be to scroll the page. Next when you move your finger the touchmove event is called. Here we just subtract the position of your finger from the scroll position we saved earlier and again prevent the page from scrolling.

So that’s it, just include these functions on your page and just call it by passing in the ID of the element you want to scroll. Like so: touchScroll("MyElement");. You can see a working demo here: http://chrismbarr.github.com/TouchScroll. I feel like this is a better way of doing things because it’s more intuitive since you’re just using one finger, and it’s potentially more obvious. Even if you don’t immediately know there’s hidden content, you might accidentally touch this while scrolling the page and realize there’s more to see in this div.

Feel free to fork or modify this code on GitHub.