Well on my way to becoming comfortable with Objective-C and Cocoa, I came across the need to create two versions of an app I was working on – one a “Lite,” and the other a full version.
Branch merging scares me
Like any good developer, I use source control management to keep tabs on my development cycles. This time, being no different than any other, I dutifully created a new branch for a lite version of my application once I completed the critical features milestone. Being one who doesn’t have a lot of use for branching in most projects, I was reluctant because (be honest here) the notion of merging back and forth between the lite and the full branches was a painful one.
Ok, I know – merging shouldn’t be that big of a deal, but what about this scenario? I’m adding some features to the full version that I decide I want to port back to the lite. Auto merging isn’t going to work (we can give the lite app all the same features of big brother), but neither am I so keen on going line-by-line every time I make a change. Cry me a river, right? Well, no. Actually, the solution is easier than that.
Enter: Compiler flags
I don’t know when I first learned about it – it could have been in my early programming days when I was learning about C – but I’ve always had ideas about compiler flags in the back of my head… very dim ideas. Look through Cocoa demo apps (check your Cocoa docs) and you’ll see several that have lines of code that seem to point to something specific:
//do something here
That’s a compiler flag. That’s the key to getting your lite version separated from the full version at compile time (or runtime, or whatever, depending on your need). Using those compile flags you can separate specific portions of code for one version of your app to another.
I’ll save you the dirty details of how you do this. Instead, head over to Junda Ong’s blog.
It’s Thanksgiving Day weekend – one of my favorite of the year – because it gives me the chance for some nice, quiet R&D time without the pressure of clients or projects asking to get things done. This week I finally made it through enough of my Objective-C/Cocoa/iPhone books that reading further felt like I was just going over more specialized use cases. For now I don’t foresee the need to have covered every topic before I get started – the basics are covered.
Of the app ideas I had going into this weekend, I chose the simplest (training wheels – crawl before I can walk, right?). It’s a Tabata timer for interval-based workouts. Nothing too special. The basic functionality is there, but I want to pretty it up and add a couple features before submitting it to the app store. I doubt it’ll really make me any money, but I did it for the exercise, not for the big bucks. I’ll post screenshots and links when it’s finished/up.
- November 16, 2009
#php, #tip, #Web Apps
[I started this post quite a while ago and forgot about it. Here it is finished. Hopefully you find something useful here]
I’ve had a few projects already where I could really use some PEAR libraries but not sufficient enough access to the server so I could install them in the system-wide PEAR include directory. I went searching for an easy to manage way to package specific PEAR libs along with apps I was building and installing for clients – something that would work without access to system-wide PHP/PEAR setup, and even in rare cases where I couldn’t write outside the document root.
First place to at least read through is the documentation. I’m going to assume you already know the basics of PEAR.
This summary will discuss the FTP method, as it seems applicable to more situations. For me – I keep my sites under version control so I need to be able to perform a local install that I can commit to the repository and either export or update on my various server environments.
* Terminal or command-line (CLI)
* CLI version of PHP
* CLI version of PEAR
Steps (code follows)
- Create a directory where you want the PEAR libs installed. Note: PEAR will create a directory named pear in the location you specify.
- CD into that directory.
- Create your config file for your local environment (probably won’t be needed on external servers unless you plan on installing from there, in which case you should create a separate config file for each site).
- Install and update packages.
- Update your app’s include paths.
- Create your config file in the PEAR directory from step 1, above. Absolute paths, absolutely!
%> pear config-create /path/to/app/htdocs/includes /path/to/app/setup/pearrc
The first path is the location where you want the files. The second path is the location where the pearrc file is located. I usually put the PEAR files in an includes directory within the site’s document root, just in case a host or client I’m dealing with doesn’t have write access in higher-level directories. It’s best to keep the pearrc file outside of the webroot, or deny access to the file via Apache’s Allow/Deny directives.
- To run PEAR commands on your local install, you will need to use the following format
%> pear -c /path/to/app/setup/pearrc [command]
(otherwise you’re likely working on system-wide changes – doesn’t help you when it’s time to deploy to the server). An example,
%> pear -c /path/to/setup/pearrc install File_CSV_DataSource
- Set your app’s includes path to search in the PEAR directory:
Change as needed.
That should do it. It’s a basic introduction, but if you already know how to use PEAR, you’re already 95% of the way there.
- November 12, 2009
#commentary, #help, #IRC, ...
Here’s a little commentary over at CakeBaker on people apologizing for being a newbie.
On mailing lists or in private mails I sometimes read statements like “I am sorry, but I am a newbie” or “Sorry for this newbie question”. And I always wonder why do those people apologize for not being proficient?
I think the apologies come from the fact that most communities has their fair share of snarky members. Case in point: I was on IRC the other day to ask a question about a new language/framework I’m learning… it was a REALLY easy answer for the experienced developer, but for whatever reason I wasn’t sure if I fully understood the concept. Among the types of responses I received, most were fairly typical:
- A couple genuinely helpful answers
- The “What do you mean you don’t get it? How can you NOT understand?” type response.
- That I should stop what I’m doing now, close the book I’m trying to learn from, and read through another book on a different subject. In this case it would be like (not the actual case) being told to stop reading the Agile Development with Rails book in favor of reading Programming Ruby 1.9.
- The non-response – nobody responds to your request for help. Mind you, I do a lot of extra work to make the barrier to helping me as small as possible.
After my experiences, I’m not surprised that people apologize for being noobs. It’s embarrassing to be made to look like a fool in public, especially when you have to ask for help because you can’t get it on your own. Now of course, I have less sympathy for people who don’t read the documentation and at least try, but if you’ve done that and it’s still a cloudy mess in your brain, ask away.
Getting close to finishing up an app for a client in the coming weeks, my business partner and I decided it would be a good idea to include some analytics code so we could track how people are using our application. We ended up using Pinch Media’s Analytics to do our tracking. It came down to this: their code is REALLY easy to implement, and they provide us with just enough information to satisfy our curiosity. I think one of the biggest draws is that it records information regardless of the user’s online status – meaning offline app usage information is stored to a small database and then uploaded once the user reconnects. Had we used a web-based solution, which would have been natural given the nature of PhoneGap (the underpinning of our application) being UIWebView, we would have missed out on some details without considerable work-arounds to cache data as Pinch Analytics does.
Moving forward, I’m likely to investigate some of the finer points of creating my own PhoneGap callback functions so I can embed Pinch Analytics Beacon methods, which are nice little ways to record information about discreet actions taken within your app – recording leader board views, for example.
I recently ran across some major performance problems with a jQTouch app running in PhoneGap. Some of the symptoms included long pauses on touch events, non-responsiveness, and laggy transitions.
Brian LeRoux (Nitobi/PhoneGap), Jesse McFayden (Nitobi/PhoneGap), and David Kaneda (jQTouch) were the stars looking into this issue. Ends up Jesse found where the Accelerometer was taking a 40Hz sample rate and sending the data to a callback. The solution is to just disable Accelerometer use – either in the plist or, as I did, comment-out all the accelerometer bits. Likewise, I removed location functionality, as this app in particular doesn’t need it.
You can read Jesse McFayden’s post here. And if you’ll excuse me, I have an app to finish…
Here’s a quick note for the frustrated:
elem = document.getElementById('myInputElement');
elem.readOnly = true;
Why it took me so long to find that out, I have no idea why. Most forums threads by others seem to think the
disabled parameter is the best way to go. Actually, the sheer number of people suggesting that makes me think it’s a bad idea – just following the crowd. This is why
readOnly might be the right option: You’re still allowed to post the form value, but the user isn’t able to change what’s inside the box. When using disabled *nothing* gets posted from that element. So if all you want to do is prevent a user from editing the value of a form element, use
readOnly. If you don’t want that value posted, then go ahead and use
I was looking for a simple solution to backup my newly constructed server to an off-site location in case something were to happen. I don’t mean I lost a file… more like catastrophic hardware failure, fire, water damage, physical damage, and even theft!. Local backups really are best, and I don’t plan on abandoning them any time soon, but in the case of the one in a million chance where something like this occurs, there’s a high likelihood that everything might be lost.
Enter Cenolan.com: How to: Incremental Daily Backups Using Aamazon S3 Duplicity. It really is pretty easy. Just one thing: besides installing Duplicity (also required a few other dependencies), I had to install Python-boto:
yum install python-boto
You may also be interested in doing regular backups of your MySQL database (from HowToForge.com)
I recently performed a major upgrade on my file server this week. It was a lot harder than it should have been, but that’s only because my Linux Foo can only go this far. Two to three re-installs later on the new hardware it was getting old, so I told the Fedora installer to just do the base package and I would worry about the rest later.
Worry is not my middle name, but frustration might be. For reasons unknown to me I thought I could just do an “upgrade” from the installer. Wrong. Then I thought maybe I could boot normally, insert the DVD, and I could then select it as a package source. Wrong. Download all those packages I missed the first time around isn’t an option on slower-than-molasses connection I have at home. So I did what any other self-respecting nerd would do – turn to Google.
The trick lies in the Yum Repos list, located in
Check it out. Normally you have three entries: Fedora, a Debug branch, and a Sources branch. The primary Fedora branch configs look something like this (I’m using Fedora 10 in my example) :
name=Fedora $releasever - $basearch
Our job is to copy and modify it so Yum and the GUI app manager can use the DVD. First you need to copy the block of code pertaining to
[fedora] and paste the copy into your file – after
[fedora] is fine.
- Change the line
- change the
name line to
name=Fedora 10 x86_64 - DVD
- change the
baseurl line to
baseurl=file:///media/Fedora%2010%20x86_64%20DVD (the path to your DVD might be different – check it first)
- delete the
- make sure the
enabled line is
enabled=1 (you can turn it off later through the “Software Sources” app)
- Save and exit
Use Yum or the Application manager to install. Rather than taxking your network and your patience you’ll see the DVD activity light busily blinking as you begin installing packages. One tip you might need to keep in mind is that refresh packages button on the package manager. There were a few packages I tried installing that were no longer available when I turned-off the net-based repo source. This is equivalent to
yum clean [option]
- March 17, 2009
#php, #sysAdmin, #tip, ...
I just ran across a nasty worm in one of my WordPress blogs (not the most current install). Not only did it overwrite a ton of files, inserting spam links and malware into the pages, but it was sneaky enough to go into my wp-admin/.svn/prop-base/ directory and re-write those files as well. It’s fairly ingenious from the hacker standpoint. Most people like me will rely on the svn revert file.php to send the file back to its original version. That won’t work if the .svn/prop-base files are altered because svn will see that they are the same – it doesn’t bother actually checking the repo, so you’re stuck with infected files.
I solved my problem by deleting the wp-admin directory and doing an svn-up on its parent. That forces SVN to say “hey – that directory is missing. I should pull it down from the repository.” Problem solved (for now).
And I am now running the most current version of WordPress, so hopefully I’m free of risk and infection from here on out.