Updates

The forces of evil are against me... I mean that I deleted Xcode to free space for movies on my (old) MBAir... and now I also have to upgrade to El Capitan. lol

Thankfully with Gigabit internet the downloads aren't gonna take long. Unfortunately, no coding for me today! 

iOS & Swift

This is where your friend and humble narrator finally takes it upon himself to learn iOS & Swift. Curiously enough, while I am working at Apple, I haven't touched either and these are some of the most incredible things that Apple has come out with. Anyhoo, making apps is (arguably) the best way forward and forward I shall go! Just simple things for now: calculators, word reversers, a simple game or two, (of course) a to-do app and some other silly things.

BUT, one app I really do want to create is one where I can use the iPhone to determine if the speed of a turntable is correct. I wont go into details right now, but when I get a chance I will!

Right- lets get started!!

Two big things, one post

Today was a fun day. A lot of the hard work I put in @ Apple paid off, and during WWDC the pages I worked on came live! YAY

Also, for the massage app, got a lot done... specifically I was happy to get much of the logic down for the Admin users. I still have not created the day-of event specs, but that is for tomorrow.

Some things I am proud of:

	def admin_user
	if !logged_in?
	flash[:info] = "please log in"
	elsif !current_user.admin?
	redirect_to(root_url) && flash[:info] = "Not an admin, cannot create events"
	elsif current_user.admin?
	flash.now[:info] = "create your event here"
	end
	end

This is actually part of a before_action I have on my events controller. I was trying to remember a way to ensure only certain classes of users could make it to a page, and thanks again to Hartl's Tutorial it came back. Check out the controller

Oh, and some super simple jQuery to hide some flash messages (like the ones above)

	$('document').ready(function() { setTimeout(function() {
	$('.alert-info').slideUp();
	}, 3000);
	setTimeout(function() {
	$('.alert-success').slideUp();
	}, 3500);
	});

I liked that... nice to get those to go away 

Oh, some interesting things w/ the app

I've tried to go about this the TDD way. I haven't been testing so much at work... well I dont even use Rails at work either :)

Some examples-

Nothing terribly difficult here, at least now, but these tests have saved me from times when I thought I was only updating one thing, but actually changed the structure much deeper.

OH, another WAY cool thing is a "seed". I want to test how this site reacts with a lot of users.

The faker gem rules and allows me to seed my db:

Also know that I created some other users there for testing (some admins, some not). Ok, back to my admin work.

Massage App

So @ AKQA we have massages and the way to signup is one of two ways:

1. A signup sheet
2. An online form

The first option is not very good because an email is sent out and then there is a rush to where the form is. Of course, if you are in a meeting, dont see the email or maybe not in the office that day you totally miss out.

The second option isn't great because of some of the above reasons and that the people who see the email first get first dibs.

Essentially, its a mad rush and I feel there must be a better way.

I am going to build an app where an admin can create an event and users can select a time for that event.

You can checkout the code here (dont ask why it is called talktome)
and a live version on heroku here

There are essentially 3 phases for this:

1. Users & Admin signup (and a confirmation email is sent)
2. An admin creates an event (which is emailed to users)
3. Users signup for events

Note- the authorization has already been written, now onto getting the admin section completed

From Zero to App Store with HTML5, APIs and PhoneGap- Making my first phone app

Thanks Richard (friend and fellow student from General Assembly) for letting me know about an awesome meeting @ Apigee to build an API driven mobile app. I've been looking for something new and fun and this is it!

I'll post the juicy details of the one day bootcamp afterwards... should be fun... 

Benchmarking, what a difference a line makes

What a difference a line of code makes
32 little lines
...
Ok, now that we have Renee Olstead's song in our heads lets get what it is I'm trying to say:

Code that works may very well not perform well. I wanted to see about writing some code to figure out the first n prime numbers. Pretty easy stuff:

I got to thinking that the downside of this is that I am running the modulo operator on each and every number. This clunkiness isn't so apparent on testing the first 100 numbers, but, what if we are talking about 100,000?!?

More to the point, how to even see what is the time spent?

require 'benchmark' => from ruby docs we can see that this module lets us see what the time factor really is.

From the docs we understand that the time breakdowns are: CPU time, system CPU time, sum of user and system CPU time and, arguably, most importantly, elapsed real time (the on in quotes: (0.000100) )

Lets change array_test(100) to array_test(100000). This will run our benchmark on our method to show us the prime numbers 1 - 100,000.

Yeah, a big time difference. Before coding I wouldda thought there would have been a linear difference, but here we see instead of it taking x1,000 more, it is x100,000. Here is our first taste of Big O, and I'll go over that later. But lets instead focus on making this faster.

Nice... ~x6 faster

what does adding (2..Math::sqrt(max)).each do |i| help us achieve?

Essentially we have to recognize that x * y =  z. If z is not a prime then there has to be two numbers x * y = z. If both x and y were are greater than the square root of n then x * y would be greater than n; This then means that x or y must be less than (or equal to) the square root of n (thanks to Edward Guiness's book for really helping me understand this).

So, instead of checking all the numbers 1-100,000 (as the iterated array using i), we can test a much smaller set of numbers.