Software development thoughts and ideas

Monthly Archives: March 2014

I run an Ubuntu server and had it all setup for some time now. I never really had an issue like today come up until now. I was baffled into what could have went wrong. I didn’t even touch it but for some reason it just broke. I noticed that I was unable to get to my site using localhost like I always use to be able to do. After doing some research I found a solution that fixed it for my server.

When I initially setup my server I followed this guide and everything worked out great. Anybody looking to setup a LAMP stack server I would recommend reading this first. Even if you think you know what your doing this guide will make sure you don’t miss anything. Okay back to how I fixed my specific issue. I noticed that it wasn’t defaulting to any project. After thinking about it for some time it came to mind maybe the default project somehow got enabled again. So the fix turned out to be very simple. I just had to disable the default project again and it works great again.

I am starting to develop a new Android application and am torn between using Androids Sync Adapter or just calling the API directly like I did with pervious applications. I can see benefits to each. I see some applications use Sync Adapters while others seem just as fast and are not using Sync adapters. It doesn’t seem like Android really has a standard of which one to choose and which situation you should choose one over the other. It seemed from my readings that Sync Adapters are the new standard but I just don’t see many applications using them. I see benefits and consequences to using each. I am having trouble choosing as I want this application to do everything to the Android standard. I see a lot of benefits to using direct API access again.

First I have been using direct API access for some years now so for me I already know what I need to do to connect to the API. I already have the code needed to perform json encoding tasks. Another benefits as I never have to worry about the data getting out of sync. The process will happen as the user saves the form or deletes the record. So the web server and application will always have the same data along with primary keys. Also if the user looses their device or gets a new device they don’t have to worry about the syncing not working. Their data is always safe on the server. To me it just feels a little more safe as I know the users data is up on the server if they get the saved response back. Otherwise they will get an error right away of errors they need to fix.

There are also some consequences to using direct API access. The biggest one is that it requires the user to always have a network connection while using the application. Some of that can be minimized by caching though. I tend to think phone networks are getting faster and have more coverage but there are some users that are unable to connect for some reason. Even with WiFi hotspots being all around again some users are unable to find them when using the application. This leave a negative impact to the user as they find the application useless without that connection. This makes it hard to complete with applications that do not require a network connection to work. Even though the data is not being sync to the cloud and therefore could be lost easily. The end user does not see this benefit in some cases.

There are benefits to going with the sync adapter method from my initial research. Which to be honest with you wasn’t a ton maybe three or four hours reading through the Android documentation. The first benefits with the sync adapter as you don’t have to worry about the network connection at all. The sync adapter handles that for you. It will check if the network is available and if it’s not it will wait tell it’s available This will give your users an offline mode while still getting the data backed up when it’s possible. Also this is built into the Android framework so it is relatively easy to learn and use. There are plenty of examples of how to use it on the web.

There are also some consequences to using the sync adapter. The first one that I see is you have to create a local schema using SQLLite that basically mirrors what your web server is doing. So every time you make a database change on your server you have to make that same change to the Android application. Also any business logic that your web server is performing has to be done the same way on the Android application. Since the sync adapter may not run the second the users submits the data you need to have your Android application verify that the data being saved will save on the web server. You could get around this by checking that the syncing process finishing successfully and if it doesn’t pass the failure onto the user at that time. The problem I see with that is it could end up frustrating the user. They might not remember exactly what they intended to do at the time. Depending on how long their device was offline for. It could be a day it could be weeks who knows. So maybe they entered a number incorrectly but have since forgotten what it was. Seems like you would have to be repeating business logic across the environments.

These are the thoughts that have going through my mind as I am starting this new application. According to Google using the sync adapter is considered the best approach. At least it seemed that way although the documentation did not say so. An example that I found on my device that uses sync adapters is Dropbox. I am not sure that my application would need such a thing. I almost feel like sync adapters are made for applications that are always looking to get data like an email client or Dropbox. You can setup syncing times or intervals. Is there a better way of getting data in and out other than these two options? Also if you go the direct API route can you cache it locally still and sync the next time the application starts up?

I did some work using WordPress maybe three years ago and wasn’t very impressed with the code base. I thought it was too cumbersome and wasn’t very well organized. So when I created this blog I initially used another blogging engine thinking that WordPress was just too bulky. I was totally wrong and after using it over the past couple of weeks I think WordPress is by far the best blogging engine.

It’s so easy to get it up and going. I actually was able to get it up and going in under ten minutes. That is from start to finish including download and upload times. I also find that the interface is very easy to use and very modern. I was able to install a couple of plugins without an issue. Very impressed with how easy the install process really is. I never really installed plugins so to me that was very impressive. No development skills needed. There is also a ton of great free plugins. So really for a standard blog no work is needed. You can literally be up and running in minutes. I don’t think I will go back to modifying WordPress code though. I believe that is where my impression came in as I was doing custom development within a WordPress site. Yes you can do this but then you start to have to deal with the internals. I am guessing the code base is cleaned up by now though. To sum it up keep it up WordPress I will be a user of yours for a long time.

I made a post a while back about Github Reliability and how I thought it wasn’t so great. Since that post I don’t think Github has been down. If it has been down it has been down very little and not noticeable in the everyday work environment. I have been very impressed by this. The reason why this post is coming up as over the last year I noticed Github being down often enough to notice. It seemed to happen right in the middle of the work day to.

I believe they have made great effort to improve their reliability. This could be a sign that they turned the corner and are now able to keep their service up and running at all times. Which is very impressive to me. See that they were having so many issues over the summer they have really turned it around. I feel it’s only right to post the good as I did post about the bad some time ago.

When I started this blog earlier this year I started it using a tool called Chyrp. This is a blogging engine in the PHP language. I am very familiar with PHP and have done it for over six years now. So having an engine in something you know is always a good thing. It looked really slick and had a smaller code base than say something like WordPress. I thought it would be easier to apply fixes when needed and I could do those fixes myself. Well after using it for about three months I have had to switch off of it. It was just having to many resource problems for me to keep it running. I suppose an argument could be made that since I know PHP I could have fixed them myself. I looked into the code base it it was just too big of a task for me to do. I just want a blogging engine not another project to put development efforts into.

This blog is currently getting about 100 users a day looking at the various posts. It seems to be more consistent now than before. So it’s becoming important to have something reliable. Also to have something that is scalable. I noticed that even with this small load of users Chyrp wasn’t able to handle it. My server kept running out of memory even if say 2 or 3 users where on it at the time. Looking into it there was about thirty apache processes running all eating up the ram. I am not sure what could have caused this as it seemed to happen maybe once a week. Even though once a week isn’t a ton it gets annoying over time. Also you always have to be on standby to get it back up and running when it runs out of memory. So I had to look for an alternative and I found one in WordPress. Even though I am no longer using it now I still see a future for Chyrp if they can fix some of these issues. I consider these types of issues major as dealing with memory issues is never fun. Until they are able to fix them I would not depend on it for a blog that has many posts that has many users viewing those posts. I am glad that I tried it out though and I still think their interface is pretty slick.