scrum is a software development methodology that works along the lines of lean manufacturing or agile. to make sure we all speak the same language, agile is lean is scrum in a superficial or high level view point. if you are wondering on the origin of the name, scrum is borrowed from rugby where the players lock up and try to get a hold of the ball by passing it with their feet. small iterations. makes sense?

the methodology assists in defining the development life cycle and stages, the key players and roles and how responsibility is delegated. scrum also assists in figuring out how to stay on top of project and it’s progress, how to address and perform changes/enhancements to the development plan and how to deal with risks. taking a step forward, scrum can help lead development teams, be engaged in drawing conclusions and improve both product and process on regular basis.

if you were a scrum, the world is roughly divided into you and waterfall. “you” means agile methodologies such as kanban and XP. waterfall is a more sequential approach from the 70s that was (probably) influenced by traditional manufacturing, and is similar to the approach of building a house:

• there are restrictions on the order of operations (one cannot lay the roof before foundation for example)
• mistakes are freaking expensive so better get it right by carefully planning and quality measuring your work
• much repetition (many doors, many windows) so consolidating tasks means efficiency

so with waterfall one first gather all the requirements for a product, then architect the solution, then dive into a detailed, technical design of each component, code it up, integrate, test test test, repair/fix and release.

with agile, developing software is more like designing a department store:

• usually there are loose restrictions on the order of the tasks at hand
• a wide array of features
• a detailed and strict planning may fail. small incremental steps and proper adjustments moving forward works better (scrum anyone?)
• centralizing tasks helps to a certain extent

scrum in action:

• with agile the team goes on sprints (2w minimum for us) when each run gets us one step closer to our goal
• effectiveness is key: how many features (stories) were coded into the system. less lines of code in general, more code that does what the end user really needs
• no elaborate MRD/PRD. with agile one maintains a backlog and direct communication. we hold daily meetings, spring planning and we retrospectively learn from our mistakes and success.
• flat hierarchy across the team and more responsibilities is handed off to the developers. the team self manages using a structured process
• a team is comprised with complementing skills, so each team can get stuff done on it’s own accord

everywhere you turn people are talking about big data, hadoop and sharding. rightfully so. in today’s day and age managing a lot of data is not an easy task, as performance and scalability are key. traversing large data sets, dividing them into tiny sections and distributing the load among many machines (processors) is nothing new.

hadoop exists in order to solve specific problems and has emerged out of necessity. what hadoop does is provide the infrastructure to connect multiple (cheap) servers into a coherent environment with which high i/o and cpu problems (algorithms) are solved.

it all started in 2004 when doug cutting of google released his document indexing project called lucene and decided to have it possible to achieve the same goals in distributed environment. hadoop BTW is his sun’s yellow elephant toy. in 2006 yahoo hired doug to improve his project so it can index the entire internet and made the project open source. that day marked the start of the revolution.

at it’s core hadoop includes two projects: one for distributed storage and one for distributed computing. around those two projects a vast of projects have evolved (and still are).

HDFS: hadoop distributed file system
this file system is designed to store large files and enable large and effective r/w. this is done by dividing the file into sizable chunks, while each chunk is normally stored on 3 nodes which can be anywhere. there is a “name node” that runs the mapping between a document and it’s constituent pieces and the data nodes on which they are stored on.

mapReduce:
an API to write programs that will run in a parallel.  the developer really needs to write two simple functions: map and reduce that handle a single document (i.e. element of data) on multiple machines, when each node is responsible for the timing, handling errors and failures (network, i/o, etc). this allows for simple parallel batching, where a “job tracker” synchronizes the execution of the bach processes, when each one batch is sub divided into smaller tasks which are handled by the “task trackers”.

over time yahoo and facbook (to mention a few) wrote their own drivers over HDFS and mapReduce and have shared their work with the community. so hadoop is a code name for a set of technologies who harnesses the computing power of many machines to perform simple tasks in parallel. hadoop emerged from the world of un structured data where hundreds of millions of pages are analyzed. today big data is being implemented and researched in every facet of the economy, including healthcare.

from mongodb.org, mongo is a scalable, high performance, open source, schema-free, document oriented database. so the one size fits all philosophy doesn’t work anymore, does it? non relational databases scale horizontally much better. just add another machine and you are good to go, and these days where big data is a big deal – speed, performance, flexibility and scalability are the names of the game. think about it… no schema, no concern with transactions. this is the commoditization of databases. what mongo does is try to perform as a key-value store with the functionality of RDBMS.

speaking of “traditional” database capabilities, mongo can index and has failover/replication support. data is stored as documents in binary JSON format. yes. mongo “gets” JSON out of the box. is your JSON valid? good. you can now import and query it. and no schema means no more ‘alter table’ crap, and the query syntax  is java script based and you can nest your queries as much as you want. moving right along, gridFS can store large binary objects efficiently . images. videos. whatever. just throw it in there.

the documents are just like records. only mongo has them as JSON binary objects. collections are your old school tables if you will. when you query mongo you get a cursor back and not a record per se, and you iterate over the set of result set like a champ. you guessed it. no more loading everything to memory – just want you need. this is a big victory for the performance gods. mongo is wonderful to perform analysis  as it is a data warehouse. dump in your JSON and analyze the hell out of the data.

mongo is not good handling transactions nor maintain the integrity of relationship between data. you can find out more at http://mongodb.org

• level1: CDA header + body of unstructured blob (pdf for example)
• level2: CDA header + xml with narrative blocks, each block is code identified
• level3: CDA header + xml with narrative blocks + entries (SNOMED, CPT, ICD-9 encoded etc)

as you can see, the richness of the data grows with each level and so does the capabilities of interoperability and quality of use. the coding for level2 and level3 is a requirement and adds clarity and consistency to the transaction. moreover, with level3, entries are encoded at varying levels of specificity, which is what HL7 refers to as “incremental semantic interoperability”, which allows the vertical and easy way into implementing the standards. as interoperability goes, the richness of the data is as important as the ability to exchange it, thus CDA level3 is what HIS should strive for, which will yield better care all across.

the new world of smart devices has changed the game. for the first time in history last month, mobile use surpassed web. it seems the direction is clear – more robust, engaging and capable devices which are portable, easy to carry and connect us on a personal/social and professional level. every vertical on the planet is thinking of mobile and it can be utilized to achieve corporate goals, save money and enhance communication within the organization.

from the early start it was clear there is one daunting issue with mobile. fragmentation. this issue persists across history, from the inception of virtual machines to the web. ask any front

end web developer of their experience with coding for an array of different browsers and brace yourself for some horror stories that will most definitely make you cherish your choice of profession. yes – the browsers claim the support and implement specific standards, but at the end of the day having a concise experience across the 90% is major pain.

not far behind are mobile devices. a developer builds an app for iOS and now wants to develop it for android and blackberry. good luck. android has more devices out there an screen resolutions than one can count, and while going native is a great idea, one will need to double their effort in order to produce a solid experience across the eco system.

forget you not that the true open standard for mobile has always been the web. steve jobs explained so in the first iphone unavailing back in 2007, and indeed some great technologies have emerged for the mobile web that allow developers to deploy/convert/cross-compile their code so it will either run natively or be compatible across many  devices and operating systems.

while that is a good and interesting market that is just starting to awake, one very quickly experiences the big gaps between mobile web and native applications. most certainly on apple devices. the experience keeps the users wanting more. yes, HTML5′s canvas and CSS3 really offer some great features that do a good job – but it’s not the same and sometimes is not as responsive. let’s face it – a big part of mobile is the experience as it drives engagement which is a big part why mobile surpassed web. just play angry birds on crhome and then launch it from your iphone and you will see what i mean.

i have always been a fan of haptic technologies. in essence haptic provides the user sensory feedback so they can “feel” the surface of the touch screen, which are great, but there is still a missing sensual experience to what one is using. my mom for example does not like touch devices and prefers real buttons. who doesn’t? touch screens take time to get used to and bar none everyone would prefer to work with a physical keyboard for tasks that are longer than 140 characters.

IMHO haptic is a game-changer and one piece of technology that will take user experience to the next level. exposing developer APIs and allowing us to provide our users not only a visual but a sensual experience of the UI elements and interact with our technology on a deeper more intimate level. it may just be what will save the mobile web. touch is stronger than visual in my opinion, especially as displays have more pixels condensed per inch than ever before. how many of you are “blown away” by the new ipad’s retina display? how many of you think it’s “okay”, but certainly not something you would immediately shell out $550 to upgrade your ipad2?

being able to program what our fingers feel as they interact with a touch screen may be what the mobile web horizontal needs so it’s experience delivery is enhanced and gain more traction and acceptance.

iOS 5.0 introduced us to ARC for mobile. this is a major change (advantage) in the way developers  work. what was once a source for memory leaks, which required diligent memory allocation and management, becomes easier and much simpler of a task, allowing developers to focus on the code.

LLVM rocks indeed.

think of it as new ‘best practices’ one should incorporate into their coding habits, while disallowing other practices:

• no more retain, release, autorelease nor dealloc
• no more custom retain nor release method implementations
• do not store obj pointers in C structures (use objects instead)
• no more direct casting between objects and non objects (e.g. id and void*)
• you are done with NSAutoreleasePool. use @autoreleasepool keyword to mark the block in curlies.

what ARC should encourage you to do is start thinking about the relationship between objects and object graphs, and not so much in terms of retain/release. there is now a new lifetime qualifiers for objects, which includes zeroing weak references. the value is automatically set to nil when the object it points to is deallocated. we now have qualifiers for vars and new weak and  strong declared property attributes.

apple is providing developers with migration tools which are build into xcode:

https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/00-Introduction/Introduction.html#//apple_ref/doc/uid/TP40004626 .

switching to ARC means neglecting support for iOS >5.0.
add custom containers to the mix, much more control over customizing UIKit elements, storyboards, tableView’s new flexibility and much more.

happy coding.

the human story for today is our need to focus. the need to do just one thing at a given moment and stick with it for many hours. developers know how to do so (hey nir, can you turn off the music and ask andrew to put his headphones on please?). i know that for me playing music does the trick and specifically practicing yoga. calming the mind is an art that requires constant and un interrupted practice. i cannot imagine the brain enjoying 100% capacity at any given moment, just as much as it enjoys 0% capacity. the truth is pretty much always in the middle. face it, we have learned to respond to these interruptions better than focus, and it goes back to the days where the telephone was invented.

sleeping is the best time for the brain to not consume new streams of data and process all it has been bombarded with, make new connections and archive/store the data. from a quick survey with close friends and family, i learn that sleeping patterns are very much affected and do worsen with time. how many of you out there in the internets sleep with the TV on?

this is why i take two long breaks from my work and focus on relaxing my mind and body, explore new geographical areas of our planet, meet new people, study a new language, and more often then not play/write music and expand my photography skills. this works in phases though and i find that it takes some time to re-adjust the mind and relax – slow down. the longest break i have ever taken from life was a 3 months trip to brasil. no iphone, no laptop, no internet connection. would you be surprised if i told you that it did not take long to re-adjust to the new situation and that i loved it? i took my best photos and wrote my best music while taking these breaks from life.

much like a hard reset, browser cache cleaning and the application of a new style sheet – one may immerge back with fresh energy and a newly re-wired brain. so – for the sake of your career, mental health and own happiness – plan on taking a longer time off. you deserve it.

what will we possibly get?

• retina display: 2048×1536 pixels will make pretty much everything more gorgeous and engaging.
• A6 quad core processor: this means tremendous performance and response boost.
• LTE support. let’s face it – 4G network is where it’s all heading,
  as the internet will blend better and tighter with the device and our lifestyle.
• better front and back camera. flash.
• equal or better battery life.
• unified GSM/CDMA support.
• bluethooth 4.0 chip.

what we may get:

• smart bezel virtual buttons:
  imagine the bezel and back cover of the ipad responding to customized buttons which lit up.
  so you can setup the top left .bezel button to launch maps. more here.
• NFC chip (not likely IMHO).
• airdrop feature from ipad to mac.

what we probably won’t get yet:

• haptic feedback display. the game changer. it will be a great day when it arrives (though the image from apple may hint at it…).
• solar charging of the device
• new map system which apple has been working on

final thoughts:

• how does siri fit in? i am not sure yet…
  will iOS 6.0 be announced as well? if so, developers will a beta by early next week…

it’s time to expand your iphone app and introduce it on the ipad. that is an interesting move for any product as the ipad is not an iphone – it is used for different things at different circumstances. yeah – you are going to practically re-think your app… which is great because you get to revisit your code and make sure your pipeline is tight, secure, fast and reliable. all that with the elegance of the ipads – split view controllers

where do one starts? well, you can start be designing your app for the ipad and take by thinking about the following:
orientation, layout and gestures. all of which vary significantly from the iphone (unfortunately). side note: one thing i really like about webOS is that you develop your mobile app once and the system takes care of adjusting the interface to a slated device.

next thing to learn about the ipad is it’s split views, popovers and specific hardware features – all of which are ipad unique. you will need to use conditional coding to learn if a specific hardware feature you are looking for is available. this is necessary as you will need to load the right resources to handle that hardware. more specifically one should write conditional coding for:

resources: in your code, recognize which platform is running and load the right nib files. you will also need to load the right graphics that match the screen size and resolution.
classes: check for class availability based on the device you are running on as some are iPad/iPhone specific.
methods: weak-link any device specific methods and perform a check at runtime for the availability of that method and wether the object responds to a specific selector.

hardware: test for cmarea/gps/gyro support before utilizing it.

okay – we are done with the overview. let’s roll up our sleeves and dig right into it.

first thing’s first – lets let xcode help us start the process by duplicating the current target (an iphone target) into an ipad one.
right click on your target and choose “duplicate”. two options here – duplicate only and duplicate and transitoin to ipad. let’s go with the later.
what xcode does here is create a new virtual folder (i.e. group) called “Resources-iPad” and copies the main nib file there. xcode really takes care of the main nib file and creates it for us. no other nib files to be touched. why? because the rest of the nib files are usually tied right into apps view controller so xcode leaves it up to us to define both the view and it’s controller. xcode sets the targeted device family (TDF) build settings to iphone/ipad and modify the base SDK of the project which will support both device types. no need to touch nor worry about the deployment target. you will see a new plist for the ipad app with it’s relevant settings.

in order to see it in action – run the app using the ipad simulator. what you will see is the iphone app running inside the ipad simulator and you can x2 time it to fit. boooo. one more step necessary (thanks apple for leaving it up to us) is to update the scheme to use the new and shiny ipad target. so go ahead and duplicate your iphone scheme (or create a new one) and under run  - choose the ipad executable. boom. wait – it really looks bad here.

well – as you may know iOS uses the MVC design pattern heavily. you may not know that MVC is actually a compound design pattern which includes 5 patterns. luckily this abstraction makes the process of porting an iphone app to an ipad a bit easier, as potentially one needs to take care of the view – making sure the right outlets are updated based on the design of the UI, and also heavily touch upon the controller to see which device is used and then follow a specific code path to match. the good news is the model can stay untouched

if you are happy with the IBOutlet you currently have on the iphone and would like to only use those (i cannot image why, but yeah…) all you need to do at this point is adjust the springs and struts in the size inspector when loading up your nib in IB. you should also make sure to support the orientations required for the app. in order to do this you will need to  implement shouldAutorotateToInterfaceOrientation:  and test for the device running the code and allow rotation. if you have singleton object place this code in it’s header file:

#define IS_IPAD   (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
#define IS_IPHONE (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone)

ipod touch returns UIUserInterfaceIdiomPhone. FYI.

or place it wherever works for you, as long as you have access to this macro from wherever. this is useful as you will need to update your controllers to test for the hardware running and follow a specific code path to update your view and outlets.

one example of using this code and auto rotating is this:

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {

	 if (IS_IPHONE)
	 {
		 if (interfaceOrientation == UIInterfaceOrientationPortrait ||
			 interfaceOrientation == UIInterfaceOrientationPortraitUpsideDown)
		 {
			 return YES;
		 }
	 }

	 if (IS_IPAD)
	 {
		 if (interfaceOrientation == UIInterfaceOrientationLandscapeLeft ||
			 interfaceOrientation == UIInterfaceOrientationLandscapeRight)
		 {
			 return YES;
		 }
	 }

	 return NO;
 }

pretty easy and straight forward right? moving along.

cautionary tale:
the app now must be careful with the symbols it uses. if you want to use UISplitViewController while running on iOS 3.1 – your app will crash as there are no split VCs on 3.1.
the way you should be thinking about this is by mentally tuning into the ‘runtime checks’ zone, where you will test if a particular symbol exists. more about that later.

updating VC and views:
this is where the bulk of the work really is – redoing your views and adding code (or creating new) view controllers. what can we do – the view size varies between the iphone and the ipad and that certainly needs to be taken into consideration. so start off by redesigning the views for the ipad. if you plan on scaling the existing view could work okay, but more often than not will not be the result you are hoping for. think of it this way – the new ipad interface should make use of the new available space and the elements which only exist on the ipad (splitVCs and popovers for example). the outcome is good UI and top UX.

also consider the following. for view controllers:
a) create new nib files for each device (if you use nib files that is).
b) if you code your views – make sure you support both devices when you do so.

for views:
a) if you override drawrect: make sure the method can draw to different view sizes.
b) if you implemenet the layoutSubviews method, the code must adapt to different view sizes.

symbol checking during runtime:   if deep down inside you had hoped that this step will somehow be avoidable – fear not runtime checks for newer symbols is easy as pie and is the type of topic you can discuss with your boss and sound really clever.
all of this is under the assumption you support different versions of the OS. just like a good soldier – you MUST protect your code from using symbols that do not exist. this happens all the time when you update an app to use new features and want to continue to support previous versions running on older OSs. all you need to do is create different code paths to follow, based on the OS currently running on the device executing your app. if you don’t do that your app is guaranteed to crash and that is not something us pros do, so let us quickly look into an example of how one goes about creating a code path when checking for newer symbols during runtime:

if you are linking against iOS 4.2 you are in luck my friend. that version has a weak linking support built right in, which allows you to check for the existence of a given class object and determine if it’s usable to you. like so:

if ([UIPrintInteractionController class]) {
   // Create an instance of the class and use it.
}
else {
   // The print interaction controller is not available.
}

seriously now – how simple was that?
bare in mind that if you want to use this feature of the OS you must build your app with LLVM and Clang.
deployment target should be 3.1 or later. sorry.

if your app links against < 4.1, use NSClassFromString to see if a class is defined. if nil is returned – you’re shit out of luck.

for example:

Class splitVCClass = NSClassFromString(@"UISplitViewController");
if (splitVCClass)
{
   UISplitViewController* mySplitViewController = [[splitVCClass alloc] init];
   // Configure the split view controller.
}

for testing if an object  can be sent a specific message (i.e. has implemented that method), use the oh so convenient instancesRespondsToSelector: class method (yes, it is a class method, it’s not a type).

if you are a registered iphone developer and have not done so – check out the SDK compatibility guide by apple.

runtime checks –> conditional code paths:
based on the interface idiom described earlier – let’s start creating cool code paths to support both devices. a simple if-else statement will do just fine thank you very much. moving right along.

This concludes this first steps required to port your app from iphone to an ipad. next is a quick rundown on how to use split view controllers in your ipad app.