Just wanted to give a quick update as to why I haven’t blogged lately. Basically, it all comes down to work!
I haven’t had time to play video games (even though I got a couple of new releases) or test out my new TV. Haven’t really been learning much Android, OpenGL, Rails or PHP (which are goals of mine for this year), or just having time for rest and leisure.
With a full time job and an impending deadline for the Pearson LiveLesson videos I’ve been pretty much recording and preparing the lessons non-stop!
As of now I still have to record 5 videos and prepare 3 of them, write the scripts for the headshots and record them by the end of this month. It’s a lot of work and I am tired, but in the end it will all be worth it and I will have time to relax later this year.
I do want you do know that I have a special article I’m preparing and will publish as soon as it’s done. It will not be a tutorial or related to programming at all, it’s going to be a different, more personal article that I want to share with you all.
Until then you have a good time and happy coding :)
Hello fellow coders.
These past days, while working with Core Data and iCloud (a real pain in the butt I gotta say), I’ve been needing some more detailed console output for debugging.
I came across a very handy tip while reading Marcus Zarra’s Core Data Second Edition book from Pragmatic Programmers.
For Core Data, there are currently three logging levels you can use to watch and analyze the SQL calls that take place during your app lifecycle. Level 1 being little output and 3 being very verbose.
To enable this option in your application you need to add a runtime parameter named com.apple.CoreData.SQLDebug and then passing in the level you want for SQL logging.
Now, if you’re using Core Data with iCloud then you can also enable a runtime parameter to observe the communication between the two. This setting is com.apple.coredata.ubiquity.logLevel and, at the time of this writing, it only works with level 3.
To setup the arguments for when the app is run go to your scheme editor, select the run configuration and enter the following:
And this is some of the added log output you can see after enabling these parameters:
Certainly something you’ll want to take advantage of when using iCloud and/or Core Data. It certainly helps not having to go check the .sqlite files constantly.
I hope you’ve enjoyed this brief tip, feel free to leave your own comments on debugging tricks and tips.
At long last, my blog is alive!
It’s taken me months, I know. I’ve even had a few visits and emails from people during that time.
I was on the brink of launching my site yesterday when some visual glitch occurred on a theme I was using and it forced me throw all of my work out the window. I was even considering Octopress to power my blog, but I decided to stay with WordPress.
Today I purchased a new theme from Theme Forest and I’m extremely happy with it. In just a couple of hours I’ve gone from a fresh install of WordPress to a full functional blog with RSS, contact form, pages, posts, sidebar, retina support, etc.
This is the beginning of something big for me, I plan on sharing a lot of what’s on my mind (it will be safe for work and kid friendly) as well as tutorials, resources and more!
Feel free to leave a comment, contact me or just enjoy the site. I know it’s pretty empty as far as posts go but it will grow in no time!
Have a good weekend,