up:
the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.]
CHUCK:
Hey everybody and welcome to Episode 9 of iPhreaks! This week on our panel, we have Rod Schimdt.
ROD:
Hello from Salt Lake City!
CHUCK:
And I'm Charles Max Wood from DevChat.tv. And due to a little bit of a scheduling snafu, it's just the two of us today! So, you get to hear more from us.
ROD:
Yeah, if I ain't got a chance to talk.
CHUCK:
Yeah. I think Pete and Ben and I all suffer from the same "we like to hear ourselves talk" and we always have something to say [laughs].
ROD:
[Chuckles] Alright!
CHUCK:
Anyway, let's get this started. Our scheduled topic today is "Interface Builder and Storyboards", which is something that I've actually played with a little bit - all the time.
ROD:
And do you have questions about it? Or, issues you want to talk about it?
CHUCK:
Not really. I mean I haven't done anything too complicated with it. And for the most part, you drag the Elements out there; you link them up with the actions on your ViewController, and it just kind of works!
ROD:
Okay. So you just want to talk about how they work and what you can do with them?
CHUCK:
Yeah, I'm sure I'll have questions. I guess one question right off the bat is what if you have some kind of like custom-designed interface? Can you do that with Storyboards or Interface Builder?
ROD:
Not really. Interface Builder are designed for most of the built-in controls. When you want to do custom work, you basically just put a View out there, set its class, and then you have to write all the custom code for that class.
CHUCK:
Oh, interesting.
ROD:
There the step on how you do it. So, if you're doing a lot of custom work, it's mostly good for just laying out the basic structure of your user interface, and then you go from there.
CHUCK:
Nice. I'm looking at it here; I actually pulled it up so I could actually look at it and ask you questions about it. But before we get into that, are there any tricks that you use to make it easier to reason with?
ROD:
What do you mean by reason with?
CHUCK:
Well just, are there any things that make Interface Builder easier to use that you do?
ROD:
No. Sometimes, I just get all the other side panels out of the way, depends on how big your UI is and how much form you need. I always leave the Inspector up, but I just pretty much use the basic what you got in Xcode.
CHUCK:
Okay. So one thing that I'm seeing here is on the left, under placeholders, it has "File's Owner" and "First Responder", what exactly do those mean?
ROD:
The “File Owner” is typically the object that's going to load this NIB. So a lot of times, that's when you call initWithViewController; you're way down on the code, someone's calling LoadNib, and it's passing itself as the File Owner and knowing that NIB has loaded that. It's kind of like an outlet that File Owners, it gets attached to that object. So, it's the class kind of that's overstaying this UI.
CHUCK:
Okay. Is that typically the ViewController then?
ROD:
Yeah. All the time, that's the ViewController.
CHUCK:
And then the First Responder?
ROD:
The “First Responder” is -- are you familiar with the ResponderChain?
CHUCK:
No, I'm not.
ROD:
I think we’ve talked about that. On any events that happened like a tap start at the First Responder. For example, when you're editing a field, you're typing in a field, that is the current First Responder. So when you type a key, the event goes to the First Responder, and he may choose to handle it or not, and he can handle it in which case it shows the keypress or not then it passes it up to the next responder in the Responder Key Chain, and then that responder has a chance to handle it or pass up so well. And eventually, it will get to the application - the AppDelegate.
CHUCK:
Alright. So I'm looking at the project that I've got open here and it says "Received actions", it also got like copy/paste, go back, go forward; I also see 2 actions in here that I created on my ViewController. So, are those events as well as this is event-driven? Or, is it more procedural?
ROD:
Well, you've got the Actions -- I call them "Advanced Actions" or kind of synonymous. So you've got all the built-in objects and they have their Events or Actions that they handle. And whenever you write a View or Class and you put that IBAction keyword in your header file, Interface Builder will look for that and make that an Action, treat that as an Action and put it in, and Xcode will show it in the Actions that you can connect.
CHUCK:
Oh, okay! That makes sense. So then you got all these objects down here in the bottom-right, it's where I'm looking, but you got Touch Objects, it's also got Custom Objects, which is empty.
ROD:
Right. It used to be that you could add your own -- they're called "Palettes" -- you could add your own Palettes to Xcode or Interface Builder at a time so that you could put in your own custom objects and put them in here and they won't work just like the built-in ones. I think Xcode 4 discontinued support for that. So it was kind of a neat feature, but they don't support that anymore.
CHUCK:
Nice. And all of these Elements that you put on there, those are Views? I'm a little confused by the terminology as well.
ROD:
Which terminology?
CHUCK:
For example, this entire layout is a View, but then it seemed like a lot of these like a label or a round rectangular button or whatever, is also called a View. Am I mixing things up here?
ROD:
What specifically are you looking at?
CHUCK:
Over here and all of the different Elements that you can drag on to here so that I can drag a label on to my iPhone layout. Are those Elements? Or, are they Views? What do you actually call them?
ROD:
Well, Label is a View, and Round Rect button is a View, all these are Views under the Controls category. And then you've got DataViews, those are also all Views. Just your recognizers are Recognizers; they're for handling taps and different pinches and all that stuff.
CHUCK:
Oh, okay.
ROD:
And then we have Windows and Bars, which are also types of Views; bar button items are, I think those are View, technical Views.
CHUCK:
And then the overall layout of where everything goes, is that also a View?
ROD:
You mean like where you place a button? The thing you place a button into?
CHUCK:
Yes.
ROD:
The rectangle that you typically see on the Interface Builder screen?
CHUCK:
Yes.
ROD:
Yeah, that's a View - that's the main View that your ViewController is managing.
CHUCK:
And the NIBs are kind of subViews, I guess?
ROD:
Right. And then you'll also have the Controllers and Objects category, and that is going to have your controllers, things like your ViewController; NavigationController also is different controllers. And they're going to control the Views; they're typically going to point to these things that you're putting together.
CHUCK:
Alright, that makes sense. Now, the other thing that I'm wondering is what is an Outlet?
ROD:
An Outlet is simply a pointer to an object, typically a View. But it could be a pointer to Controller or your own custom object, and you can connect them up in the Interface Builder. But really, it's all just a pointer.
CHUCK:
Okay. And then the other thing is this, this has Storyboards so you can add multiple Views and when you'd say this button takes you to this other View, that kind of thing. Now, how do you usually wind up wiring that up?
ROD:
Well, you have what they call "Segues" - Segways. And so you just drag from a button or another View to your other View, CTRL+drag, and then it'll ask you what type of Segue you want, a little menu will pop-up and you can still push on model or custom. You can create your own Segues, too, in code - custom code. Or, there's also a relationship key so like a Tab Bar Controller, has all of these Views in these separate tabs so you can say "This is just one of the ViewControllers".
CHUCK:
Okay!
ROD:
So, it's pretty simple.
CHUCK:
Awesome. I don't know that I have a ton of questions about this. I mean it is pretty straightforward and pretty visual.
ROD:
Yeah, there's also exit Segues that they had it in Xcode or iOS 6 where you can -- it's a little confusing to hook up iOS after looking the documentation. You see those little green squares with an arrow going out of it at the bottom of ViewController?
CHUCK:
Hmm-mmm
ROD:
Those are “Exit” Segues, and that's how you go back; they had adept feature.
CHUCK:
Okay.
ROD:
Now, one issue we can talk about is, there's kind of a growing movement where people don't want to use Interface Builder. And, there's also issues with using Storyboards in a group setting - a team setting.
CHUCK:
Okay.
ROD:
Things like that…
CHUCK:
So, why wouldn't you want to use Interface Builder?
ROD:
Some people, especially in the RubyMotion crowd and more and more in just plain object to seek out, is they don't like the idiosyncrasies of Interface Builder, how every time there's some bugs in Xcode where like if you sort of just select a XIB or a NIB, it changes the file and you don't really know what it has did in its XML and you can't really read it. So, people just prefer to do it in code because they want that extra control; they feel more comfortable with it.
CHUCK:
I've had a few people tell me that Interface Builder is pain.
ROD:
Yeah. I think there's a misperception that -- I love, personally I love NIBs, and that's what first drew me in their platform when I first saw an X machine -- so people think that it actually generates code, but that's not the case at all. The objects that you put on in your NIB are actually real objects and make it serialized to a file. And when the app runs, they get unserialize so your real object gets instantiated and no code is generated at all. That XML file, that XIB, is just a serialization of real objects that you've created.
CHUCK:
So for example, each Button and each Label is an object that's been serialized into your XIB. And then when it gets compiled to a NIB and then pushed up to the machine, when it opens up that NIB, it says "Oh, I've got an object of this type and I know what to do with it".
ROD:
Right. It instantiates and connects up all the outlets and everything.
CHUCK:
That makes sense. So, are there any downsides other than some of the weird gotchas to using Interface Builder or were just building it yourself?
ROD:
There's the team environment, you have two people working on a NIB. Because of the way Xcode works now, you don't know what it did to the XML so it was hard to merge. This really comes into play when you're using Storyboards because there's so many NIBs in the Storyboard; if you touch one you'd screwed up [chuckles] everyone of them. So I'm not sure how people deal with it, but I mostly deal with it myself - alone. I've worked in team environment with just NIBs and it hasn't been an issue. But Storyboards, I've just -- over the weekend, I was doing startup week and a couple of weeks ago and we just have one person do the Storyboard stuff. And then we would have, if we wanted to split up work, we would just have someone do a NIB and connect them up later in code.
So, that's kind of a bang; I hope out fixes in the future version.
CHUCK:
Yeah, I guess it makes sense, though, because the system is like Git - they just, too, kind of a lineby-line comparison and if they don't line-up and it doesn't know which merged thread is you to use, then you get weird characters in your code.
ROD:
Yeah. Or, it's just the fact that it changes so many things in the XML file that don't seem related to what you did and it makes you touch the Storyboard; it changes stuff and what did it do, you don't know.
CHUCK:
Yeah, that makes sense.
ROD:
It's pretty annoying. The other issues, if you’ve done a lot of custom work, we've already talked about that, then you don't really need it; you can just set up your basic layout and that's it.
CHUCK:
So, how would you do that? How would you approach that?
ROD:
You mean writing the custom UI?
CHUCK:
Yeah. How would you write a custom UI?
ROD:
Basically, I'd set up a NIB that has just the basic structure, like maybe I just have one master View, and that's it. And then say I had, just for simplicity's sake, we had a custom View in there, you've dragged a plain old UIView as a subview of your main View, you'd create a new class for that View -- let's say you're creating a custom button -- so you'd create a subclass of UIButton. So you drag a UIButton into your View and then you go into your Inspector. And on the third tab, there's a class field at the top, you can set its class to your custom class so when that NIB has load, it's going to instantiate your custom version of a button. And then you just code your custom button, overwrite how it's drawn, how it handles events, etcetera.
CHUCK:
So to that degree, you would actually use Interface Builder to get it where you want it?
ROD:
Just to set up the shell.
CHUCK:
Okay.
ROD:
And so it will load all the objects for me, basically, and instantiate the right kind of UIButton I want. And then from there, my code takes over to draw the button, handle the events, whatever custom stuff I wanted to do.
CHUCK:
Yeah, that makes sense. Are there certain Elements or certain Views that you use more often than others in the Interface Builder?
ROD:
Well, I use the Controllers a lot - NavigationController; TableViewController is probably the most widely used Controller with the corresponding Table View, you see those everywhere. Those are only the ones - NavigationController, TableViewController, and ViewController, and TabBarController are probably the most widely-used.
CHUCK:
Yeah, I'm seeing these in here; there's TableView, CollectionView, and NavigationController, TabBarController, PageViewController, GLKit Controller...
ROD:
Right.
CHUCK:
So, what are all of these? Because don't you generally just start out with a ViewController?
ROD:
Well, that depends on what you want to do. If you just kind of have a generic View, yeah, you'd start with a ViewController. TableView is whenever you want a display of view list of things, then you use a TableViewController. CollectionViewController is a new thing that in, I think, iOS 6 that's kind of like a TableView except that it displays things on a grid.
CHUCK:
Okay.
ROD:
And you can also customize how it lays the tech grid out; you can make it do it in a circle or whatever. NavigationController is for when you want to drill around in the things --
CHUCK:
Meaning that if I have, say, I'm building a contacts list for some reason, so when I tap on the contact, then it loads up the data for that contact?
ROD:
Right. So you'd have a NavigationController and then inside the NavigationController, you'd have a TableViewController displaying your list of contacts. And then when you tap on a contact, it pushes another View, say, just a plain old ViewController, and it has the detail for that contact that pushes it onto the NavigationController. And the NavigationController animates it on the screen, keeping track of the previous TableView that's now offscreen. So, it's got a stack of ViewControllers that it's managing.
CHUCK:
Okay!
ROD:
And then of course, we have TabBarController, which is a bunch of tabs with the Views; each one of those could even be a NavigationController. PageViewController is like pages in a book, so it just like iBooks; you can even have the page bending as you flip the page.
CHUCK:
Yeah, that's an animation I'm not figuratively fond of [laughs]. [Rod chuckles]
CHUCK:
But, I have seen it.
ROD:
Yeah. You can even see the back of the page as you animate; incredible detail in there. GLKit View Controller is for games. So if you want to have a View with a GLView - OpenGLView - you'd use that. A lot of people, though, when they do games, they don't even use the Interface Builder. And I could see the reason behind that; there's not much need for that. Although, typically, they'll set it up with just a single window that has like GLKit be open, and that's it.
CHUCK:
Yeah.
ROD:
I think that's what the template does; there's a GLKit template or something.
CHUCK:
So, let's say that I put Navigation stuff in there, or I put a list that I can go out and see kind of a subview on these different things, so I would use a Navigation View for that or NavigationViewController for that. When I hook that up, does it -- I guess the TableViewController is about our example of this -- so if I hook the TableViewController up, does it know that I'm building a Table in my View and set that up for me? Or, is that something I have to build up myself?
ROD:
Well, if you drag the TableViewController from the side here, it'll create everything that you need.
CHUCK:
Oh!
ROD:
So if you drag out, so it's got a ViewController, it's got the TableView inside of it, everything you need! And all is hooked up, the View outlet is hooked up, I think there's a TableView outlet as well.
So, it hooks up all the basics.
CHUCK:
Yeah, I just dragged it up there and it created another View so then I could set up the transitions and stuff you were talking about.
ROD:
One thing we didn't talk about with TableViewControllers and one of the advantages of Storyboards is Static Cells and Prototype Cells. So normally, it used to be when you created a TableView, to get those individual cells, you had to overwrite the datasource method and then create the cells and code and set them up that way, and then there's like 4 types of cells that you could return a different type. But when you wanted to do your own custom cells, you had to do a lot of work; you had to create your own NIBs, and then load those NIBs at the right time and do that, and it's kind of awkward. But then with Storyboards, you can create custom cells and all your static cells right in the Interface Builder. So if you have a Table that's always displaying the same cells, that's what we call Static Cells, and that works well for that. You notice you can select the cell in this TableViewController if you drag it out in the Storyboard. Is that what you did?
CHUCK:
Yeah.
ROD:
And then if you look in the Inspector, you've got a style for that cell; and if you select like basic, a
title shows up. And you can also set an image for that cell, and then see static cells.
CHUCK:
So, Static Cells are those cells that don't scroll when you scroll everything else? Or, that it's something else?
ROD:
No, it just means that they never change. The TableView is always going to display these same cells.
CHUCK:
Oh, okay.
ROD:
So, your data is static.
CHUCK:
And if your data is not static?
ROD:
If your data is not static, then you can use what they call it as a Prototype Cells. There's somewhere where you set the -- if you select the TableViewController (no, that's not it) -- there's somewhere where you tell the TableViewController that you want static cells. Oh, here we go! If you select the TableView and then you have a content setting and you can select Static Cells or Dynamic Prototypes. So Static Cells, we just talked about; so you can basically create your whole table and all the content right in your Interface Builder. Dynamic Prototypes is for your contacts. Example, you have a list of contacts, all the cells tiles are going to be the same, but their contents are going to be different. So, you may want to have an image, each person has an image, and they have a name, and then under the name, maybe you want to show their title or address or something. Then you can say "I want Dynamic Prototypes" and then select your prototype cell, set its style to subtitle, add image placeholder, and then that's what it's going to look like. You can also have more than one Prototype Cell. So say you have a company, your contact list has list of companies and people, you could have a company prototype cell and a person prototype cell.
CHUCK:
Oh, interesting!
ROD:
And then you get each of these prototype cells and Identifier - a Cell Identifier. And then in your Delegate and Datasource Methods, you just say "Give me a cell with this identifier", say a company identifier, and it'll give you that prototype cell and then you fill it in with the content, and you're off.
CHUCK:
That's cool!
ROD:
Yeah! So, that's a really nice feature of Storyboards; you can't do that with just plain NIBs.
CHUCK:
So when people are going outside of Storyboards or Interface Builder and they're doing their own thing, do they still compile NIBs?
ROD:
No! There is just straight code at that point.
CHUCK:
Oh, okay.
ROD:
Yeah.
CHUCK:
So all of this is manipulable by code, you just say "I want an object that at this position, that's of this type", and that's basically the same as re-inflating the NIB when you get it on the device?
ROD:
Right. Basically, you could write Interface Builder yourself if you wanted to with all the Cocoa APIs.
CHUCK:
Oh, nice! So how do I get -- because I'm playing with this a little bit -- how do I get a TableView cell into the TableView?
ROD:
With Prototype Cells?
CHUCK:
Yeah, or any of those. So I have the TableView and I don't see a way of saying "I want this kind of cell” in there.
ROD:
Well, you've got one cell already, right? You can click on the cell that's already there. Because when you dragged out the TableViewController, it created a Prototype Cell.
CHUCK:
Okay.
ROD:
Right? You can duplicate that cell, probably give you another cell, and then you can give that a different identifier. So basically, you've created another Prototype Cell. If you select the TableView again, there's also -- below the content where you select Dynamic or Static -- there's also a thing that says "How many prototype cells there are?" and you can set that to the number of Prototype Cells you want.
CHUCK:
Oh, okay!
ROD:
And then it'll create those cells and then you edit those however you want. You might be able to even drag the cell out from the Controls.
CHUCK:
Yeah, I tried doing that and it didn't quite do what I expected. Anyway, I'll have to play with it and figure it out. I don't particularly like talking about things visually...
ROD:
Yeah, it's hard to.
CHUCK:
On a podcast, where people can't see what I'm doing. So I tend to just go along with this same kind of thing. So on your apps, you have the Numerology App and -- is that the only one you have?
Or, do you have another one? I thought you have another one.
ROD:
Well on iOS, I have Numerology and Numerology Baby Namer. I did Favors, which was a passkit app, but it got rejected. It got approved, and then the update got rejected, and then they said "You can't have this app on the store". And, that's it. I had one Bone Word at one point. Those are my iOS apps; I had some other one Mac app, too.
CHUCK:
Now, did you use the Interface Builder on all of those?
ROD:
Uh-huh!
CHUCK:
Alright.
ROD:
Yup.
CHUCK:
So one other thing that I've heard about, but I haven't actually experienced yet is that, if your interface doesn't follow certain guidelines from Apple, that they will reject it. So for example, on the iPhone, if you allow the upside-down orientation, they will reject you, is one thing I've heard.
ROD:
[Chuckles] Really? They support upside-down orientation so I don't know why they would reject that. It's in your Xcode settings, so you can say that you support it. So, I don't know why they reject that. Xcode, it's really hard not to follow the guidelines in Interface Builder. When you drag things around, it shows guides and stuff, but you don't have to follow those, and you won't get rejected like if you don't have the right margin or something like that.
CHUCK:
Yeah. The other one I heard was that, say you have a list and you can tap it to expand it and see all the information about it, or if you tap and it does certain other things, you have to use a certain arrow icon.
ROD:
Yeah, there's guidelines like that; there's two different decolumn disclosure controls, I think that's what they're called.
CHUCK:
Uh-huh.
ROD:
Accessory controls is one, it's just the chevron like the gray arrow --
CHUCK:
Yeah.
ROD:
And that means that you're going to drill down into something; you're going to display another view or detail for that. And then there's also a Disclosure Button, which is like a blue button with the disclosure arrow in it. And that's also used to represent that you're going to bring up some detail that not necessarily drilled down. They have guidelines that go along with all of these things. But unless it's -- I've never been rejected for how I'm not following guidelines --
CHUCK:
Oh, okay.
ROD:
So, I'm not sure when they would reject you. I think you would have to be a pretty blatant misuse of it.
CHUCK:
Okay.
ROD:
Yeah. Some local developers' role is to track a music player, which basically looks like a metro app on your iPad. So, you have a lot of flexibility with what you can do.
CHUCK:
Alright, cool. It looks really cool. I'm just looking through these other things...It looks like there are quite a few different Views and things. One thing that I'm curious about is can you set up custom Gestures?
ROD:
You mean in the Interface Builder?
CHUCK:
Yeah.
ROD:
As you see, look at these 6 built-in gestures that you just drag on to your View and then connect them up, but you can create your own gestures; you just have to do it all in connect development code.
CHUCK:
Okay. So you have to recognize where the contact points are and then --
ROD:
Yeah, there's a UIGestureRecognizer Class that all of this is inherit from. And so you could inherit from that, too, and then overwrite the right methods to do what you need to do to recognize whatever gesture you want.
CHUCK:
Okay.
ROD:
But for custom one, you'd have to connect it up and code; you wouldn't be able to do it in Interface Builder.
CHUCK:
Okay. I don't know if I have any other questions about this.
ROD:
Okay. I think I've covered all the issues. Someone who doesn't like Interface Builder would maybe bring up some more issues that we haven't addressed.
CHUCK:
Right. I mean I definitely have a certain sympathy for people who want to control it all through code. But at the same time, I'm also one of those folks that's pragmatic enough to go. Well, if I don't have a beef with the Apple generic look and feel for an app and I can get all of this interface stuff done in half the time or less, then I'm probably just going to go with the Interface Builder.
ROD:
Yeah. I mean even if you done a lot of custom work, you can get a lot set up that your framework setup and then you can customize it from there. I remember, before Interface Builder, I wrote UI code like in Windows or with the Java Swing API, and you just sit there all day going back and forth, switching that coordinate year, and go back to your code, run it, and see if it work, lines up where you want, then go back and tweak it some more; you'd spend a lot of time doing that. If you don't use Interface Builder, it's the same thing and I really don’t like doing that. Where in Interface Builder, I just visually put it where I want, the guide show me where they recommend you put it, and I'm done. When I run it, it looks the way I want it to.
CHUCK:
Nice.
ROD:
And even connecting up Actions, you just drag from a button to an Action and it's hooked up to write any code.
CHUCK:
Yup. So one thing I did notice that it doesn't have that I find a little bit surprising and a little not surprising at the same time, because they don't have a CalendarView. They have the DatePicker, but they don't have a CalendarView.
ROD:
Right. There's a lot of controls that you wish they had. And they exist out in the open source world; people have written their own widgets. So search CocoaPods, you'll probably find a calendar control. And if Apple brought in back in support for your own custom controls, that’d be actually be in Interface Builder.
CHUCK:
Oh, okay.
ROD:
That would be nice.
CHUCK:
But as it is, what you do is you pull in a View and then you tell it to use the CalendarView instead?
ROD:
Right. You set its class to that new class that you imported from CocoaPods, or you just hook it up in code.
CHUCK:
Interesting. Alright, well, I don't know if there's anything else to talk about. I don't want to drag this out if we don't have stuff to talk about.
ROD:
Right.
CHUCK:
So, why don't we go ahead and get to the picks? And then, we'll wrap up the show!
ROD:
Okay!
CHUCK:
So, I'm going to make you go first.
ROD:
Alright! My first pick is "Episode 97 of NSBrief", where he interviewed Jon Reid on Unit Testing and Clean Coding. I went and watched some videos that Jon Reid made about Unit Testing with Cocoa and ViewControllers and it really got me interested in trying it myself. I haven't really done much of that, but he shows out a Test ViewControllers and everything, and so it got me interested in doing it and trying it. So, that's my first pick. And then my second pick is "Ember.js". I've been just fooling around with JavaScript and trying to see what all the excitement about is, and I liked Ember.js; I've started prototyping an app. Ember.js split off from SproutCore, which was Apple uses to do their web apps, and that's got a lot of in common with Cocoa, but it's written in JavaScript so I like it so far.
CHUCK:
Very nice. Yeah, I listen to the NSBrief, too, and I really enjoyed that episode. I'm kind of a code quality geek and I like hearing what other people are doing.
ROD:
Yeah.
CHUCK:
So, I think it was really cool. And yeah, I also wound up having lunch with Saul Mora the week after we talked to him on the podcast, and (he's) super guy.
ROD:
Yes, he seems like a really nice guy.
CHUCK:
Yup. He was trying to talk to me into coming out there for a 360iDev and stuff. But anyway, my picks, my first pick is a book that I found that I'm going to start going through. It's not strictly iOSrelated, but it probably has more relevance to your backend if you have an API that you're connecting to for a data and stuff, and that is "Seven Databases in Seven Weeks", that just seem really cool.
ROD:
Yup.
CHUCK:
So, I'm probably going to work through that.
ROD:
I read the Seven Languages in Seven Weeks book.
CHUCK:
Yeah, I've got that one, too. I need to go through it, but I just haven't had a chance. And incidentally it's funny because both of those books have one primary component of my regular stack, and that is Ruby on one and Postgres on the other. But I've been playing with MongoDB and stuff, too, and I'd like to understand it a little bit better. And this seems like it's kind of a one-week crash course into at least the basics.
ROD:
Yeah.
CHUCK:
So, that's one pick. And then the other pick that I have is "Eventbrite". I've been using that; I'm actually going to be doing this afternoon Debugging Ruby and Rails online training, and it's free. But by the time this comes out, it'll be too late for you to sign up. Though, you can get a copy if you go to railsrampup.com and join the wait list for the course. Incidentally, it just makes it really really easy to set things up to sign up for things. So, I've used it for that, I've used it for a few other online trainings that I'm doing, I've used it for the actual Rails Ramp Up Course, and I'm also using it right now for -- I've had several podcasters approach me and talking about some of the issues that they have with FeedBurner and some of the concerns of whether it's going away -- and so I'm using it to have people sign up to come to a discussion; it's kind of an informal discussion. But basically, to get an idea of what they need and what they want and what kind of Azureus they would like to use for that. And then, I'm considering actually building a product or under it if I feel like there's enough interest and need for it. But anyway, so all of the events stuff that I do is basically run through there, and it's really really nice. And, those are my picks!
ROD:
Alright.
CHUCK:
Alright, well, we'll wrap this up. We'll catch you all next week! Thanks for listening!
ROD:
See yah!