Posts in Work methods (90)
App: Sparrow (desktop) / (iPhone)
Price: $10.99 (desktop) / $2.99 (iPhone)
Why we like it: Light email client with a polished and very compact twitter-app-looking interface. It integrates with dropbox allowing you to automatically upload attachments just by drag-&-drop on the email body. The attachment then is replaced with the dropbox download link.
It's common to use a centralised "Constants" class where you gather together lots of constants for your app. For example, in Objective-C you'll often have a big file Constants.h full of lines like this.
- #define DEBUG_MODE NO
- #define APP_URL @"http://itunes.com/apps/mycoolapp"
- #define CHARACTER_ANIMATION_TIME 2.0f
- #define FOOTER_IMAGE @"mycoolapp-footer.png"
- #define FONT @"Helvetica-Bold"
Don't do this.
1. It increases compile times significantly. Because lots of other classes depend on Constants.h (it's common to include it in the .pch header file so all files have access to it), any small change to Constants.h means that every class in your application will need to be recompiled. And ironically, during development at least, constants are often variable
2. It makes unit testing more complex, adds additional dependencies and discourages re-use. Because many classes depend on Constants.h, its harder to test them in isolation. Moreover, you can't easily transfer classes between projects, without manually checking which parts of Constants.h needs to be copied too.
Instead, it's much better to place constants in the class which they are used in. If you have a true need for a global constant, but it is for a value which you might want to frequently change during development (such as the DEBUG_MODE boolean above), consider using a macro to load the value from a config file, for example you could define a key in the Info.plist:
- #define DEBUG_MODE ([[[[NSBundle mainBundle] infoDictionary] objectForKey:@"APP_MODE"] isEqualToString:@"DEBUG"])
Next time you need to transfer a file between computers and are about to reach for a USB flash drive, think about the following two cases. If either of them matches, you have an alternative! As icing on the cake, you can use either method whether you are on a Linux, Mac, or Windows-based system.
A very nice feature that Github added some time ago on Issues 2.0 is the ability to refer to and close issues when doing a "git commit" via commit message:
git commit -m 'just fixed issue #123'
That's nice, but what if we want to keep that issue open, change its state, or assign it to a different person in the team? As an example, what if I'm working on a bunch of issues, and I want QA to test them before they get closed?
Well, we have two ways of doing this:
1. Open your web browser of preference. Go to Github.com and sign in. Find the repository of the project you are working on. Find the issue you want to modify on the issues page of the project. Get amused by that very friendly user interface. Add/change the labels to the issue on the right panel. Assign someone to the issue using the "gears" drop box icon. Easy!
2. git commit -m 'updated issue #123 ~QA =steve'
If you are like me and would like to do option 2, keep reading! (If not, do option 1 a few hundred times and maybe we'll see you again soon! )
Luckily, Github user bluescripts wrote a very simple ruby app using the Sinatra web framework that can be easily hooked up into our project's repository using the Github Service Hook: Post-Receive-URL. This Sinatra app can be deployed and hosted on Heroku which gives you some free monthly Dynos enough for this purpose.
Here are the steps to get this app running on Heroku:
1. Go to Heroku.com and sign up for an account (free)
2. Download and Install the Heroku Toolbelt (Mac / Win)
3. After installing the Toolbelt you will have access to the "heroku" command from your command shell, type in:
$ heroku login
Enter your Heroku credentials (email/password) and upload your SSH public key.
If you have any trouble on this steps please refer to the Heroku quickstart guide.
4. git clone this project @ https://github.com/bluescripts/github-postcommit-shinie and then cd into the project folder
$ git clone https://github.com/bluescripts/github-postcommit-shinies.git
$ cd github-postcommit-shinies
5. install the heroku gem
$ gem install heroku
6. install the bundler gem
$ gem install bundler
7. run bundle install to setup your bundle locally
$ bundle install
8. add and commit the Gemfile.lock file
$ git add Gemfile.lock
$ git commit -m 'Gemfile lock'
9. create the app on the Cedar stack
$ heroku create --stack cedar
After running this command you will see something like this:Creating falling-moon-8152... done, stack is cedar
http://falling-moon-8152.herokuapp.com/ | email@example.com:falling-moon-8152.git
Git remote heroku added
Copy and save the deployment Heroku URL of your app, we will use it later. Also you can check this URL on Heroku/myapps.
10. deploy your code to Heroku
$ git push heroku master
11. check the status of your app
$ heroku ps
If everything goes fine you will see your app up and running.Process State Command
------- --------- ------------------------------------
web.1 up for 1m bundle exec rackup config.ru -p $PORT
Now go to the Admin page of your Github repository and click on the Service Hooks button on the left menu then click on the Post-Service-URLs button and paste your Heroku URL of your app and click the Update Settings button. Done!