Google I/O 2012

Google I/O 2012 starts tomorrow and I’ve taken some time off to attend the I/O Extended event organised by the London GTUG. Foolishly I have made plans for my mornings so I think it’s going to be a couple of heavily caffeinated days to make it through!

I’m honestly not sure what to expect from the keynote. Obviously there are rumours flying around and many “leaks” of the Nexus tablet, but I haven’t yet seen anything that’s going to make me go “yeah, I didn’t see that coming and that looks pretty cool”. Last year that slot was filled by the Android @ Home section so I live in hope that we’re still going to see something I haven’t already heard rumblings about. Or lots of details on Project Glass. Yep, I’ll happily settle for that!

Anyhow, beyond the keynote there are lots of interesting sessions. Might have to try to stream some on the night bus journey home to catch up on the many many clashes!

Little Green (Accented) Bag

For a few years I’ve been sporting a Timbuk2 messenger bag.  It’s a really practical bag for carrying all my gadgets if I’m travelling and can comfortably make space for everything from my laptop to my camera and lenses.  Unfortunately it’s not perfect for every situation.  Sometimes I need a smaller and smarter bag to just cart around a laptop, book and a few cables without having to find space for both myself and it on a crowded tube.  Enter the WaterField Designs Muzetto.  I’m lucky to have some awesome friends who clubbed together to buy this for me for my birthday and it arrived this week.  Their website has some good photos and videos to cover the features of the bag, but I’ve included some of my own photos below.  After a week of use I can happily corroborate any of the statements they make about the bag: it’s sturdy, looks (and smells … mmm cow) great and is incredibly comfortable.  It has no problem holding my MacBook Air, charger, a couple of books and assorted pens and cables.  The gold lining genuinely helps when it comes to digging around inside the bag to find that missing micro-USB cable.  It should also be noted that the front pocket is neoprene lined and, while I don’t think it’s designed to do so, perfectly fits the 13″ MacBook Air (obviously this is the 13″ version of the bag).  I don’t really want to do this regularly as it’s a useful pocket for a tablet so this does highlight one of the drawbacks of the bag – there’s no dedicated laptop partition to protect my Air.  Of course this also means that the bag is flexible for when I don’t want to keep my laptop with me.  WaterField recommend getting one of their sleeve cases with the bag but I was surprised at how bulky they looked and I didn’t want to reduce the overall bag space so found an alternative option.

Pros

  • Looks great!  The leather is lovely and will weather well to give the bag more character over time.
  • Well designed.  Just the right number of pockets to throw bits and bobs into.
  • Comfortable.  The bag hangs well and the shoulder strap is comfortable and non-slip.

Cons

  • I’ve become incredibly protective of it in the first week of ownership so rarely put it down!
  • Could do with a thin protector to segregate a laptop from the rest of the bag contents.

So, I mentioned above an alternative option to the WaterField SleeveCase.  The only real requirement was that it should protect the surface of my MacBook from superficial scratches.  I searched around for some basic microfibre cloth sleeves, but couldn’t find quite what I was after.  WaterField actually do a nice looking suede jacket sleeve, but I was too impatient to wait for UK delivery.  Enter the Joli Originals MacBook Air Sleeve.  These simple end-loading sleeves are hand made from felt sandwiched between Italian leather.  They come in a range of colour options and I decided to go with the classic Black & Red combo.  Now, the sleeve itself is great.  It’s a tight fit, but not so tight that you can’t get your MacBook in and out.  It should serve well both as an in-bag protector and a carry case in its own right.  This is a very simple product so there’s not much more to say about the product itself, but it’s worth mentioning the delivery presentation.  On opening the cardboard envelope it was delivered in I was faced with a handwritten thank you note and the sleeve itself beautifully wrapped in illustrated tissue paper.  OK, so that has little value after the initial impression, but it gives me confidence that a lot of care has gone into the making of this product.  See the photos below for more details.

Pros

  • Looks great.  The coloured felt middle shows around the edges of the sleeve, making it easy to spot and identify your sleeve!
  • Well constructed.  The sleeve is a perfect fit and seems solid.
  • Joli seem nice :) The personal touch is really appreciated for a product like this.  I’ll certainly be buying from them again (have my eye on one of their wallets).

Cons

  • None I can see yet.

Learning Awesome Cross Stitching

Well, I’m still not smoking and am working on the backlogs of tasks.  Many of my targets are ongoing ones, but I have managed to learn one of my target of “5 new things”.  Cross stitching.  Yep, you heard me right, cross stitching.  OK, so you may be asking a few questions.  Why is probably quite high up the list.  What may indeed help to explain why. How might appear if you’ve managed to get past why and what.  Anyhow, I digress. Let me begin with …

 

Why

To fully explain why I have been cross stitching I’m going to have to walk you through my thought process.  I have a friend from university who I introduced to Buffy back in the day.  She has since developed a full blown Whedon addiction.  Her thirtieth is coming up and someone (not me) came up with the bright idea of making a quilt for her.  Everyone was to contribute a patch.  This prompted the following thoughts:

  1. Crapola.  I’m not creative enough for this.
  2. Maybe I can attach something pre-embroidered to a patch.  I’m sure I’ve seen some Serenity patches before …
  3. Nope.  That’s not going to work.   How about printing, maybe I can find some Whedon based pictures.
  4. But there’s a risk they’ll be low quality on fabric.  What about pixel art?
  5. Aha!  A hit for … no, wait, that’s cross-stitched pixel art.  Hmmm.  How hard could that be?
  6. (2 weeks later) Bloody hell that took a lot of time …

And so my cross stitching skills gain a +1.

What

As mentioned above, I ended up stitching a pixel art pattern.  Etsy to the rescue with an awesome Pixel People pattern of the Buffy gang!  There are a few different Whedon patterns on there – I’ve provided links below – and the Buffy one seemed like an achievable goal.  This pattern is sold as a grid pattern to print along with a list of the coloured thread needed.  The colours are listed for three different common manufacturers of thread so it’s not hard to find a source.  I bought mine online from Sew and So along with needles and an embroidery hoop.  I really can’t recommend the latter more.  While it’s possible to do without, for a beginner it makes life a lot easier and allows you to stop at will with less chance of tangling things up.

The Patterns: Etsy Buffy Pattern  Etsy Dr Horrible Pattern  Etsy Firefly Pattern

And the work:

How

So, seems pretty cool huh?  OK, not so much, but it could make a great gift for someone someday so maybe you want to give it a go.  For my transformation from no-hoper to stitching hero I dug deep into the wonders of the internet for help.  The video below is an excellent five minute introduction to all you need to know to start cross stitching.  It’s worth paying attention to the bit on how to neaten up the back of your cross stitch as that pays off with the flatness of the finished product.

For the additional wording below the pattern I used StitchPoint’s cross stitch writing tool to compose the text and then copied this onto my Buffy character grid.  Easy peasy lemon squeezy.

The Thirty Project

Yesterday I turned thirty years of age.  Feels a hell of a lot like 29 to be honest.  Looking back at my twenties, I’m reasonably happy with my achievements.  Graduated from Oxford, wandered my way up Kilimanjaro and started a promising career in the City.  Not too shabby, but I can’t help but feel I could’ve done more with the last decade.  Unfortunately I’m both lazy and easily distracted by new projects, so this year I’ve decided to set myself some goals to try to reach by this time next year.  I’m going to see how much I can work tech into each of these to help achieve my goals.  So, to the list:

  • Drop a waist size.  Nothing like working in London to fatten you up, time to sort that out.  Should give me a good excuse to try out some fitness apps.
  • Write 3 apps.  I’ve got a backlog of ideas and I need to commit them to code.
  • Buy a house.  It’s time.
  • Finish a game backlog.  I have so many games on Steam / PS3 that I’ve never played.  I need to catch up on these so I’m going to go through one platform and clear the backlog before adding anything new.
  • Visit a country I can’t remember.  This may seem like a strange way to phrase this, but I was born in Canada and left when I was very young.  I may choose this year to return.
  • Set up a new site.  I’ve got an idea and I need to actually get it done.
  • Learn 5 new things.  Might be languages, horse riding, another instrument.  I’ll work this out as the year goes on.
  • Quit smoking.  Occasional puff is alright but they’ve been taxed to a ridiculous price in the UK.  Oh, and apparently it’s not healthy or something.

Apple Implements Annoying Fake Security

On my way home this evening I read about the Battery Health app for giving information about my MacBook battery.  Sounded like a handy thing to have so I fired up the App Store when I got home and tried to install it.  I say “tried” as no sooner had I entered my Apple ID password as I was faced with this window.

Security Info Window

“Bloody hell”, thought I, “more stupid question/answer pairs to remember.  Well at least they haven’t …. oh no.”  Yes, not only have Apple gone in for the security question theatre but they’ve also gone and implemented a fixed set of questions rather than allowing them to be personalised.  Beyond that they’ve gone for the “trendy” approach of asking non-standard questions.  No “what’s your mother’s maiden name” type questions here.  No, it has to be about your favourite teacher, car, and other such guff.  I’ve copied the options you’re allowed to select from below.

The Fixed Security Questions

Well, this is just bloody brilliant.  Possibly these questions do mean something to you and you can always pick the same answer from your mind, in which case these could be secured more easily than any password by using some social engineering or looking at Facebook.  If, on the other hand, the questions mean nothing to you (and, as I’ve mentioned before, it’s amazing how many idiots implement lists of questions that don’t apply universally) then you’re either going to get stuck every time you have to answer them or you’ll end up writing them down somewhere.  How very very secure.  Maybe you think I’m being a bit over the top in accusing Apple of providing a useless set of questions, so let me ask a simple question.  Given that one fifth of the available questions depend on car ownership, how many people in the world have never owner a car?  Now, as an alternative, how many people don’t know their mother’s maiden name?  While the standard questions one finds in these types of forms have no benefits (or indeed detriments) in terms of security level, at least they do tend to cover a wider range of people.  Better yet, why not offer completely customisable options?  Oh yes, because it’s Apple and Apple knows best.

Unfortunately Apple’s technical support have not been particularly helpful so far, only suggesting I raise a ticket for iTunes feedback.  Well, that doesn’t exactly help me install new software on my Mac or update (say to improve security) existing apps.  Oh well, once again I realise why I absolutely loathe Apple as a software maker.  Love their hardware, hate their systems, hate their policies.

For a good explanation of where this sort of authentication came from and why it’s utterly daft, head over to The Daily WTF to read about Wish-It-Was Two-Factor authentication.

Spending Time to Save Time: Automating My Builds

As a one man developer it’s very easy to fall into patterns of bad habits with the development process.  I don’t have a team to worry about, I’m not beholden to any code reviews or quality metrics and it’s just me and my PC, so why go the extra mile to do things right?  Some things have clear benefits and such a small up-front effort requirement that they’re a no brainer.  I have a svn repo running on my NAS and this has saved me many a time – do not underestimate the sinking feeling you will get when you realise the drive that just failed in your PC was the one with your dev environment on it.  Even if you don’t have a seperate server for source control, it may be worth considering a local install and then regular dumps of your repository to external storage.

OK, so that was quite an easy example.  Job done, point justified right?  Well, not quite.  I’d like to share an example of another area where a little bit of upfront effort has made my life easier: automation in the build process.  Now, to be clear, I’m not talking about a full end to end build process / CI here.  At the moment I don’t see the value in that beyond providing me with an excuse to spend money on a server.  Any changes I’m making in code I’ll be immediately deploying to either a simulator or device depending on my current requirement.  There is, however, one key part of my build process that needed some automation and that’s creating art resources.

I’ve written before about the tools I use to create sprites: Inkscape, Blender and TexturePacker Pro (with a splash of Paint.NET) all come together nicely as a toolbox for those who aren’t up to creating graphics by hand.  The thing is, when I want to tweak a sprite, change something completely, add something new or provide assets for multiple resolutions I have to go through a hell of a process to manually deploy this to a build.  Let’s take creating a new menu button as an example:

  1. Create the menu button in Inkscape
  2. Save this somewhere sensible that I’ll find again later
  3. Export the region I want at a scale for the app sizes I want (1080p, 720p, SD, etc.)
  4. Store these exported files somewhere
  5. Open up the texture atlas definitions for each app size and add the new assets
  6. Export the new texture atlases and their indexes and save these somewhere
  7. Copy the new atlases into each project that uses them and rebuild

The process doesn’t differ much for making small changes to existing sprites.  As you can imagine, this results in me looking at to-do items demanding I perform a bit of an art clean-up, sighing and then ignoring them in favour of playing with some new code.  Not a great position to be in. Looking at the above process, there’s clearly a lot of scope for automation and process improvement.  I’ve probably made a lot of things more difficult than they need to be as this was my first project.  Luckily, all of the apps I use come with command line functionality that provides what I need to make my life easier.  By making a few design decisions I now have a three step process:

  1. Create / edit Inkscape / Blender files
  2. Run batch script
  3. Rebuild apps

Nice eh?  To do this I’ve set up my environment in the following way:

  • All projects now look for texture atlases in a root project folder called Resource[X]\textures where the [X] is a number indicating whether the resources are HD or not
  • All Inkscape / Blender files are designed with the assumption of a HD screen to display on and placed in a Textures path within the project directory
  • Sub directories within the Textures path group the texture source files together by theme (uicontrols, menus, decorations)

The batch script (Windows version attached) iterates over each sub-directory and uses Inkscape and Blender to output full resolution PNG exports of each file to a temporary directory, divided up with the same sub-folder structure.  TexturePacker Pro is then used to create an atlas from each of these sub-directories.  This is run three times as TexturePacker Pro will handle reducing the size of the atlases for the different resource sets (I use three multipliers – 1, 0.7 and 0.5).  All that is then left in code is to import the atlases and refer to the textures within by name.  While the process could certainly be made more efficient (by not re-working items with no changes), this isn’t necessary for my personal needs.

If you want to look at the details of the arguments I use on the command line, grab the batch script and take a read.  It’s not amazingly complicated but the effort required to create it more than pays for itself.

The script: generate_svg_to_png

Blackberry PlayBook Development: First Impressions

I should open with a summary. My first impressions of developing for the PlayBook have been very good overall. In the past I believe RIM haven’t made things that easy for many developers to get started on their platforms. My account was originally registered in 2009 when I used to own a BB, but I quickly gave up when faced with requirements to get notarised ID, etc. etc. Some of these problems apparently existed earlier in the PlayBook’s life as well but RIM has taken note and clearly been working to make things better, but there are still some opportunities for improvement. I’ll tackle my first impressions with getting set up to develop for the PlayBook by theme: registration, tooling up, development, support and publication. With all of these I’ll try not to dwell on timelines too much – there has been a massive influx of developers and apps thanks to the PlayBook giveaway and it sounds like RIM have been swamped dealing with this.

Registration
Initial sign up as a vendor for the BlackBerry App World is a fairly simple web based affair with few pitfalls. As an independent developer you will be asked whether or not you will be charging for apps. I believe this can be changed later. If you do opt to put apps up for sale then you will not have your vendor account activated immediately. You will be sent an e-mail requesting proof of ID and this is then reviewed by the App World team. In my case this was turned aroundin a couple of working days and they were happy to accept scans of my UK driving license as proof of ID and address. This is a big improvement over my experiences of a few years ago where more expensive options involving notaries were involved. There’s also no charge to register as a vendor these days, which is certainly competitive given the Play Store $25 up front and Apple’s annual $99 fee.

There’s not a lot of room for improvement here. Two small things spring to mind:
1. The generic ID requests aren’t very helpful. There needs to be more details of what is acceptable, especially for international vendors.
2. I now have seperate accounts for the vendor portal, the forums and the BB Jam Zone. Wouldn’t it make more sense to do this as single sign on, possibly linked to the BlackBerry ID.

Tooling Up
There’s quite a range of platforms available for development on the PlayBook: C++, HTML5, AIR, Android. The choice for each developer is likely to come down to where they may have existing components to re-use and any cross-platform considerations. Personally I went for the C++ native SDK route and my choice was driven by wanting to use a particular framework (cocos2d-x).
All of the tools you need are freely available on the BlackBerry Developer site and you don’t need to register to download these so you can have a play with them before you commit to the world of RIM. Along with the development environments / eclipse plugins offered, there is also a PlayBook simulator. This runs on VMWare Player in Windows or VMWare Fusion on a Mac. For native SDK development, the QNX IDE (built on Eclipse) is a nice clean tool and integrates well with the simulator running in the VM.
Getting my hands on the tools was one experience where there is definite room for improvement. I’ve got the following gripes I’d like to see disappear over time:
1. You want me to download how much?!? These things are absolutely massive. Additionally I can’t see any updating path that doesn’t require a full re-install (certainly updating both the ndk and simulator from the beta required a full update). This is quite a fail IMHO – take a lesson from Android’s SDK manager, not Apple’s delivery of an installer through the App Store.
2. Do not try to force a downloader plugin on me. I like my browser how it is thanks. I have to reject the install before I’m even offered a direct link. In all honesty, I wouldn’t have minded so much except when I first tried the downloader plugin it downloaded everything and then kept delivering broken installs. Avoid like the plague.
3. VMWare Player is fine. It’s free and only requires an irritating registration with VMWare. VMWare Fusion, however, is a retail product – I like to develop on my Macbook Air when I’m on the move so this has basically forced me to outlay thirty quid to keep my simulator running. Bravo RIM, bravo.

Development
RIM have provided a few examples to get you kicked off on the dev side. These are helpful, but what is even better is that RIM really seem to have embraced bringing Open Source components into their platform. There’s a whole page dedicated to open source components that have been tested with the PlayBook. This is especially handy for game development – no need to ween yourself off Box2D!
Documentation is present, but I found it rather hard to navigate. In my opinion it could do with a bit of work on the layout of the docs. There are a few too many pages that don’t provide enough cross linking to help you dig into further detail, instead just leaving you in loops where pages link back to each other. I have more than enough of that using HMRC’s website.
All in all I can’t complain about developing for the PlayBook. I didn’t run into any real problems beyond the standard PITA of setting up environment variables on OS X. Only one improvement suggestion here:
1. Give me a local copy of the docs please! KTHXBYE.

Support
Support for developers by RIM has blown me away. Even ignoring the idea of pushing devices out to people as a reward for publishing an app, I’ve seen a great level of support in the few weeks during which I was getting Flip! migrated.
The Developer Support Forums have some genuinely useful people on as well as BlackBerry personnel chipping in with helpful answers. There’s also a good BB dev presence on Twitter and their Blog. I’ve been impressed with the level of engagement from people like Alec Saunders and Alex Kinsella as well.
The only issue I have is that their forums are a little clunky and aren’t always easy to search or navigate. I’d really like to see a community wiki growing at some point as this would help flesh out any gaps in the documentation.

Publication
Publishing to the App World is done through the vendor portal. The portal allows you to maintain your application descriptions, prices, screenshots and releases. It also provides facilities to set up test “sandbox” account to test purchases without having to make an actual payment.
All releases to go onto the App World go through a review and testing process. Much like Apple’s offering, there doesn’t appear to be a lot of transparency around exactly what goes on in this process. From anecdotal evidence on the BB Dev forums, this lack of transparency extends to rejection feedback, which may irritate many developers. I haven’t experienced this personally so I won’t say any more. The review SLA is 7-10 days, and by all accounts they are able to hit this (outside of free PlayBook madness periods). On releasing an update with minor changes, the review turnaround seemed even quicker so I can only guess that the update reviews are a lighter version of the initial approval.
Once in the App World, I could easily search for the name of my app and find it (you hear that Google?). Unfortunately there’re a couple of issues with the App World. For one, the screenshots seem to be getting massively downscaled at the moment so appear very pixellated. The second problem for me was that the RIM view of links to the App World seem to be all about going to single apps rather than vendors. The web portal for the App World does offer a way to view all apps by a vendor, but the PlayBook itself (and so the calls you can make in the native SDK) does not. This seems really odd to me as it seems a no brainer to allow publishers to present links saying “hey, did you like this? Have a look at our other stuff then!”
The one other problem I have with the App World over the Play Store is that I have to use my real name as an individual. I don’t exactly go to great lengths to hide my identity on the internet, but in this case I like to put everything under “floor4″, something I’m not able to do here without registering a name to trade under. I understand, however, that this is a very personal gripe so I can’t really hold this against RIM.

So my overall experience with developing for the PlayBook has been good. There are certainly improvements to the process that could be made, but I’ve never seen a process that couldn’t do with tweaking and RIM certainly seem to be trying to introduce more and more improvements. At the end of the day, it’s another market and well worth your time to investigate. With BB OS10 around the corner you never know, RIM may just get back in the game and make us think of the top three of the mobile world rather than just the two (oh … and WP7 I suppose …).

Development Update – February

Another gap in posting, but a productive one. In January I was investigating some cross platform Lua based frameworks (Moai and Gideros) but between a skiing holiday and recovering from injuries sustained while on a skiing holiday I didn’t get beyond a few proof of concepts. Both are worth a look, and I’ll probably return to them in the future, but my investigations were derailed by this post on the Inside Blackberry Developer’s Blog.

So, with PlayBook OS 2.0 comes (limited) Android support and RIM were offering PlayBooks to developers who submitted apps within a timeframe. Hard to resist really (and it’ll be interesting to see how this pays off). As I have no willpower I went ahead and signed up, hoping to easily repackage Flip! for the PlayBook. I ran into immediate problems as (among other things) native code in Android apps is not yet supported, but this provided me with an opportunity to pick up one of my other to-do list items and learn to use cocos2d-x along with relearning C++ so I could re-build Flip! using the BB Native SDK. I’ve now completed this and just had the app approved on the App World! I eagerly await my new shiny shiny and will tell all about it when it arrives.

I’ll get a post up this weekend about the process of signing up for PlayBook development and my first impressions.

CPU Wars Volume 1.0

I buy a lot of random geeky stuff (evidence: the second copy of Aliens vs Predator for PS3 I bought only so I could get another plastic facehugger), but one of my geekiest recent investments has to be CPU Wars Volume 1.0, and I couldn’t be happier. CPU Wars is the brainchild of Harry Mylonadis and his project has just come to fruition after successful Kickstarter funding. CPU wars is a top trumps game featuring the specs of thirty different CPUs. Ever had an argument with a friend about whether the Phenom II is better than the Core i5? No, neither have I, but now you can and the result can be decisive (SPOILER ALERT: the Phenom II is inferior in all but one category)! Anyway, head over to http://www.cpuwarsthegame.com to check out more on the history and future of CPU Wars and to pick yourself up a deck or two.

Master Chief Looks Up The Specs For 343 Guilty Spark

Yet Again OS X Pokes Me In The Eye (or OS X Environment Variables)

I bought myself a Macbook Air last year to replace my ageing laptop. The theory was that I’d be using cross platform apps so the underlying system didn’t matter. Or rather it didn’t matter enough to outweigh the pretty :)

Anyway, not all of the niggles I have are down to OS X (Apple’s “we must have our own way” GB keyboard is bloody awful and seems designed to piss off developers), but many are and I’ve just come across another. Trying to set consistent environment variables across all apps, regardless of whether terminal based or launched from an icon is an absolute mess. Worse still, Apple doesn’t seem to offer any standard friendly configuration methods for environment variables. Pricks. Anyway, the best resource for troubleshooting these that I’ve found recently is this post on stackoverflow. I’ve reproduced it below in order to ensure it is captured and kept!

There are several places where you can set environment variables.

  • ~/.profile: use this for variables you want to set in all programs launched from the terminal (note that, unlike on Linux, all shells opened in Terminal.app are login shells).
  • ~/.bashrc: this is invoked for shells which are not login shells. Use this for aliases and other things which need to be redefined in subshells, not for environment variables that are inherited.
  • /etc/profile: this is loaded before ~/.profile, but is otherwise equivalent. Use it when you want the variable to apply to terminal programs launched by all users on the machine (assuming they use bash).
  • ~/.MacOSX/environment.plist: this is read by loginwindow on login. It applies to all applications, including GUI ones, except those launched by Spotlight in 10.5 (not 10.6). It requires you to logout and login again for changes to take effect. There is no reason to use this one any more.
  • ~/.launchd.conf: this is read by launchd when the user logs in. It applies to all programs launched by the user, GUI and CLI, on 10.5 and 10.6. Additionally, you can apply changes at any time by piping this file into launchctl (maybe grep ^setenv first if you have other commands you don’t want to run). Then the new variables apply to any application launched by launchd from that point on. This means you should restart Terminal.app for the new variables to cascade down into the shells it launches.
  • /etc/launchd.conf: this is read by launchd when the system starts up and when a user logs in. They affect every single process on the system, because launchd is the root process. Again, to apply changes to the running root launchd you can pipe the commands into sudo launchctl.

The fundamental things to understand are:

  • environment variables are inherited by a process’s children at the time they are forked.
  • the root process is a launchd instance, and there is also a separate launchd instance per user session.
  • launchd allows you to change its current environment variables using launchctl; the updated variables are then inherited by all new processes it forks from then on.

Sample setting an environment variable with launchd and storing it into your personal config so it works for your login even after your reboot:

echo setenv REPLACE_WITH_VAR REPLACE_WITH_VALUE >> ~/.launchd.conf
echo setenv REPLACE_WITH_VAR REPLACE_WITH_VALUE | launchctl

Now, launch your GUI app that uses the variable, and voila!