try {
return true;
} finally {
return false;
}
Hey all!
Just some updates on what I've been up to!
I've been bored at home lately, so now my door unlocks itself based on Bluetooth proximity.
There are 4 separate services, all tied together by MQTT.
Service 1 : Simply polls for my phone using bluetooth, and publishes a simple "YES" or "NO" on a channel in MQTT. It's the only thing with credentials to that topic.
Service 2 : Simple MQTT to Arduino service. Listens specifically for a state to transition to "LOCK" or "UNLOCK", also listens for servo values for manual adjustment. Sending "LOCK"/"UNLOCK" sets the servo to a predefined position. The service communicates to the Arduino over serial. (Yes, I could just get an enet shield to do this... but no ethernet near the door.)
Service 3 : Rule manager. Listens to the phone state, as well as a few other things (time of day, day of week, prior decisions) to determine when to send "LOCK" or "UNLOCK". He's the only thing with credentials to send on that topic.
Service 4 : GCM Notifier -> Simply lets me know when a state change happens. Listens on the same topic as the second service, but issues a GCM message to my phone to let me know.
http://www.youtube.com/watch?v=QusIOcBlV2Y
Just wanted to give a quick update
Completed my first 5k today!!! 25:01!!!!! And I stopped to tie my shoe in the middle haha.
Just a little link to prove it, and a picture!
http://edge.raceresults360.com/queencity/kJBGXh/results#/person:&entry_id=585:13628458002050
Let's face it, development is hard.
Good development, is even harder.
At work recently I've been put on kind of an "under the radar" team, meaning, we're free to do kind of whatever we want to get the job done. It's actually been awesome, and given us (the developers) an opportunity to use our tools of choice to make things happen. We, of course, needed a source control solution, but we wanted to push the boundaries a bit. Our company doesn't currently do any type of continious integration, so we figured we'd give that a shot. And then we needed a way to distribute our app (an iOS app in this case) for our Enterprise only. So here's our setup, and some helpful hints along the way.
First and foremost, I'm a firm believer in Git. No problems with Mercurial, but I just like Git. Sue me. For our app, we put it in a private BitBucket repository, but you could reasonably do this internally (or externally) on just a simple (hopefully secure) SSH server. (Though, you lose the shiny of BitBucket's UI +Android App) There's nothing hard about this, and is in fact quite common. Xcode also treats Git repositories nicely, so there's that. This is easy, and I expect most of you to have this done already.
Where the real fun comes in is when Jenkins comes into the mix. Jenkins does a couple of things for us, and it's just plain awesome.
Basically, while this may not be the best practice, we assume anytime we "push" to BitBucket, we've made a change we want to roll out to devices. You can adopt or change this workflow as you see fit, just create a branch and adapt accordingly. But essentially, you'll end up with a branch that when updated, you'll want those changes to be pushed to everyone (after testing, of course)!
We have Jenkins setup to poll BitBucket (Sorry, we'd use BitBucket to push, but our Jenkins instance isn't exposed to the web) every so often, and when it sees a changed to the branch it wants, it starts a build!
We use the Xcode plugin with Jenkins, but there were a few gotchas and tricks we employed to make this... how do you say better?
First, provisioning profiles and developer certs. This is the most painful part of an iOS build, hands down. Getting the right .mobileprovision file to Jenkins, and your certs can be a huge pain in the rear. In my digging around the internet, we managed to find a script that will fetch a specific .mobileprovision file to your device. AWESOME. No anytime we add a device on the portal, no more messing with getting that updated file to Jenkins, he grabs it himself. The certs, don't change. Jenkins just keeps a copy of them.
We also have Jenkins, upon successful build, move the end result files to a distribution server, powered by the awesome open source HockeyKit. We also update a "change log" with out commit messages... by aliasing some git commands to an environment variable, and spitting those into said change log.
Then, if everything worked, the next time the device launches the app, they get a little note saying, hey, there's a new version! We've had good experiences with it so far... If there's interest, leave a comment and I'll break it down more, and give the source and config for all of it.
Til then,
Happy Developing!
Expectations are a funny thing.
You waste so much time guessing what your life could look like,
But the thing is
You can't really know until the day you open your eyes and see
That if you let go and lean into the unexpected
It may be something more beautiful than you could have ever imagined
No, it's not what you expected.
It's something even better.
The New Normal
It's the sense of touch.
Any real city you walk,
You brush past people.
People bump into you.
In LA, nobody touches you.
We're always behind this metal and glass.
I think we miss that touch so much,
That we crash into each other just so we can feel something.
Crash if a phenomenal movie.
Just needed to put this out there... an awesome guide to getting the API right for your product.
http://blog.programmableweb.com/2012/07/19/what-makes-a-great-api-the-five-keys/
I see your point.
This penny has the best view in Charlotte.
