By Pamela Cook Dreyer
This blog post is the second in a series of posts I decided to write because I felt sharing the recent challenges with making decisions about implementation of new and updated web projects could be a help to people. Part 1 dealt with the process and frustration we went through to decide which advanced web development and database tools to use. This post will describe the process of learning the tools and about how we gained information on how to install and use our server. This will also include the process it took to rewrite the website using Ruby-on-Rails.
Anyone that has worked on web design or web development knows that you not only have to deal with the functionality & security of the website but how to make it look attractive and inviting enough to attract repeat visits. We took the time to rethink our approach to the website that I am rewriting using Ruby-on-Rails. The project has expanded dramatically. The web development process has taken a bit longer than expected because of the expansion of the project AND completely changing the color scheme of the website after a lot of programming had already been done. During this process I began to feel that phase one would never be completed. Three steps forward, two steps back at time. With all of that being said we know that the new version of the website will look a whole lot better that the first two versions with far more functionality, hence making it more engaging for users. I have been able to jump over major hurdles the past week or so. I am so glad for that.
With our previous web projects we purchased hosting accounts to host them. However in the summer of 2011 we decided to purchase a Mac Mini Server for development and to start with as a production server. We decided that the first thing we would learn how to do would be to transfer all our web projects to our own server. In theory this was a simple process. However because of limited knowledge in (1) maintaining servers and (2) what happens to make websites work under the hood this became a lot harder than expected. Thankfully the Apple Enterprise Support team is absolutely the best technical support department I have ever worked with. That is saying something considering I have been in the technical field for 30-35 years. With other companies, including paid support, the tech support given in many cases has been frustrating at best. Some teams were so bad that I quit doing business with them. Thankfully we have not had any trouble with the Apple team, only great assistance.
I don't know if this is how things are taught in schools today but Bernard and I have found that the documentation being provided for software these days is woefully lacking in details that we have been used to seeing in the past. This point has probably caused a lot of the challenges we have faced more than anything else. For example, in my previous post I mentioned a wonderful tutorial that I used to learn Ruby On Rails called the Ruby On Rails Tutorial by Michael Hartl
. The tutorial included screencasts where you could watch how he performed the tasks in developing a Rails application. From time to time he would mention how you might get certain errors during the development process. His answer was to 'do a Google search'
for information on how to resolve any new errors you experience. The problem this causes is that people using only God knows what combination of software packages on God knows what kind of computer with only God knows what operating system will post an answer that worked for them but might not work for you. I would have loved to have a book that I could have purchased dealing with these issues but none were available. However resolving Rails errors was not that bad since a single version of Ruby-on-Rails will be the same for all systems except for some differences between executing the applications on Windows, Mac or other operating systems. However resolving server issues is another story altogether.
Those reading that have worked a lot with servers probably know a lot of this already but this was a major part of the learning curve for us. I thought I was a geek-ette before but after this season of web development I have become even more of a geek-ette. YIKES!! I did not realize that you really need to watch the software that you install on a server. I was thinking that it is a computer like any other computer. However with a lot more functionality in server software more things can go wrong. Using a computer for personal use you may check how software is installed but maybe every now and then you might corrupt something. However if something gets corrupted on a server an entire server service can get messed up - the famous domino effect. I have heard server people discussing this before but it did not mean all that much to me until we had our own LOL. Believe me when I say that I am a lot more careful about how I use the server and more importantly what software I install on it.
I will not go into too many details about this other than to say I have wiped clean our server I believe four times since purchasing last year. I was experiencing problems that I could not identify the source of. We had decided before calling that it might be good for me to wipe the server clean. The representative concluded that what was happening was because my OS had gotten corrupted. I had installed so many things on the server that I could not tell what was causing the problem. One thing I probably will not do this time is to install Microsoft products that are made for the Mac, they suck in IT parlance! I will also be a lot slower to install programs that I will not regularly use. Wiping the server clean helped me solve several problems that I had been trying to solve for a long time.
We decided that we wanted to eventually host all our websites on our server to have more control over their contents and security. We also plan to offer other services for our web ministry which require that those sites are hosted on our server. The process for hosting Rails applications is different from hosting straight HTML5 websites. You need to use a Rails server of some kind in order to test and deploy your Rails applications using localhost. When you develop a Rails application you manually turn on the Rails server, such as Webrick or Trim, using a terminal. This is not pragmatic when running production Rails applications because of the slow speeds of the regular localhost Rails server. I had tried Phusion Passenger months ago but had major problems getting it to work. We thought that we might need to find a commercial solution, such as Heroku or Amazon Web Services (AWS), which we did not want to implement at this juncture. Thankfully after wiping clean the server I was able to implement Passenger and begin to host our Rails application.
I have learned a lot more things through this process of learning the tools my husband and I will need to become "Entrepreneurs... God's Way". At the Church we attend, one theme that is communicated on a regular basis is 'endurance is the key'. Believe me when I say that endurance has been severely tested at times. However it is worth continuing to achieve the goals that we believe the Lord wants us to achieve. I hope that these will give some insight and hopefully bring some encouragement to those of you that may feel like quitting in the process of reaching your goals.
See you next time..............
Update: I started writing this blog post soon after publishing part 1. Since then I found out that a local community college offers classes on Ruby and Ruby on Rails. I will be taking the Ruby class starting on August 20, a few days from now. I hope this class will help me feel more comfortable with the new Web 2.0 and 3.0 concepts. This will be my first college class since 1995. Boy a lot has changed since those days. If you want to be successful these days you may need to be open to the possibility that additional schooling may be in your future. Sigh. I thought I was done with college. Oh well:)
Return to LightBe Corp Homepage