POPULARITY
7 episodes with Interface Builder
6 episodes with Interface Builder
2 episodes with Interface Builder
2 episodes with Interface Builder
4 episodes with Interface Builder
2 episodes with Interface Builder
2 episodes with Interface Builder
4 episodes with Interface Builder
3 episodes with Interface Builder
More Than Just Code podcast - iOS and Swift development, news and advice
This week we discuss Apple's all-in-one keyboard computer patent. Apple launches inaugural Entrepreneur Camp for Latin founders. Apple to rolls out iOS 15.4. We also cover Apple's Peek Performance Event introducing M1 Ultra, Mac Studio, Studio Display, iPhone SE 5G, iPad Air with M1, and Friday Night Football on Apple TV+. Picks: Hello Mac OSX Tiger, Sophie Wilson creator of the ARM Instruction Set.
We had this Mac lab in school. And even though they were a few years old at the time, we had a whole room full of Macintosh SEs. I'd been using the Apple II Cs before that and these just felt like Isaac Asimov himself dropped them off just for me to play with. Only thing: no BASIC interpreter. But in the Apple menu, tucked away in the corner was a little application called HyperCard. HyperCard wasn't left by Asimov, but instead burst from the mind of Bill Atkinson. Atkinson was the 51st employee at Apple and a former student of Jeff Raskin, the initial inventor of the Mac before Steve Jobs took over. Steve Jobs convinced him to join Apple where he started with the Lisa and then joined the Mac team until he left with the team who created General Magic and helped bring shape to the world of mobile devices. But while at Apple he was on the original Mac team developing the menu bar, the double-click, Atkinson dithering, MacPaint, QuickDraw, and HyperCard. Those were all amazing tools and many came out of his work on the original 1984 Mac and the Lisa days before that. But HyperCard was something entirely different. It was a glimpse into the future, even if self-contained on a given computer. See, there had been this idea floating around for awhile. Vannevar Bush initially introduced the world to a device with all the world's information available in his article “As We May Think” in 1946. Doug Engelbart had a team of researchers working on the oN-Line System that saw him give “The Mother of All Demos in 1968” where he showed how that might look, complete with a graphical interface and hypertext, including linked content. Ted Nelson introduced furthered the ideas in 1969 of having linked content, which evolved into what we now call hyperlinks. Although Nelson thought ahead to include the idea of what he called transclusions, or the snippets of text displayed on the screen from their live, original source. HyperCard built on that wealth of information with a database that had a graphical front-end that allowed inserting media and a programming language they called HyperTalk. Databases were nothing new. But a simple form creator that supported graphics and again stressed simple, was new. Something else that was brewing was this idea of software economics. Brooks' Law laid it out but Barry Boehm's book on Software Engineering Economics took the idea of rapid application development another step forward in 1981. People wanted to build smaller programs faster. And so many people wanted to build tools that we needed to make it easier to do so in order for computers to make us more productive. Against that backdrop, Atkinson took some acid and came up with the idea for a tool he initially called WildCard. Dan Winkler signed onto the project to help build the programming language, HyperTalk, and they got to work in 1986. They changed the name of the program to HyperCard and released it in 1987 at MacWorld. Regular old people could create programs without knowing how to write code. There were a number of User Interface (UI) components that could easily be dropped on the screen, and true to his experience there was panel of elements like boxes, erasers, and text, just like we'd seen in MacPaint. Suppose you wanted a button, just pick it up from the menu and drop it where it goes. Then make a little script using the HyperText that read more like the English language than a programming language like LISP. Each stack might be synonymous with a web page today. And a card was a building block of those stacks. Consider the desktop metaphor extended to a rolodex of cards. Those cards can be stacked up. There were template cards and if the background on a template changed, that flowed to each card that used the template, like styles in Keynote might today. The cards could have text fields, video, images, buttons, or anything else an author could think of. And the author word is important. Apple wanted everyone to feel like they could author a hypercard stack or program or application or… app. Just as they do with Swift Playgrounds today. That never left the DNA. We can see that ease of use in how scripting is done in HyperTalk. Not only the word scripting rather than programming, but how HyperTalk is weakly typed. This is to say there's no memory safety or type safety, so a variable might be used as an integer or boolean. That either involves more work by the interpreter or compiler - or programs tend to crash a lot. Put the work on the programmers who build programming tools rather than the authors of HyperCard stacks. The ease of use and visual design made Hypercard popular instantly. It was the first of its kind. It didn't compile at first, although larger stacks got slow because HyperTalk was interpreted, so the team added a just-in-time compiler in 1989 with HyperCard 2.0. They also added a debugger. There were some funny behaviors. Like some cards could have objects that other cards in a stack didn't have. This led to many a migration woe for larger stacks that moved into modern tools. One that could almost be considered HyperCard 3, was FileMaker. Apple spun their software business out as Claris, who bought Noshuba software, which had this interesting little database program called Nutshell. That became FileMaker in 1985. By the time HyperCard was ready to become 3.0, FileMaker Pro was launched in 1990. Attempts to make Hypercard 3.0 were still made, but Hypercard had its run by the mid-1990s and died a nice quiet death. The web was here and starting to spread. The concept of a bunch of stacks on just one computer had run its course. Now we wanted pages that anyone could access. HyperCard could have become that but that isn't its place in history. It was a stepping stone and yet a milestone and a legacy that lives on. Because it was a small tool in a large company. Atkinson and some of the other team that built the original Mac were off to General Magic. Yet there was still this idea, this legacy. Hypercard's interface inspired many modern applications we use to create applications. The first was probably Delphi, from Borland. But over time Visual Studio (which we still use today) for Microsoft's Visual Basic. Even Powerpoint has some similarities with HyperCard's interface. WinPlus was similar to Hypercard as well. Even today, several applications and tools use HyperCard's ideas such as HyperNext, HyperStudio, SuperCard, and LiveCode. HyperCard also certainly inspired FileMaker and every Apple development environment since - and through that, most every tool we use to build software, which we call the IDE, or Integrated Development Environment. The most important IDE for any Apple developer is Xcode. Open Xcode to build an app and look at Interface Builder and you can almost feel Bill Atkinson's pupils dilated pupils looking back at you, 10 hours into a trip. And within those pupils visions - visions of graphical elements being dropped into a card and people digitized CD collections, built a repository for their book collection, put all the Grateful Dead shows they'd recorded into a stack, or even built an application to automate their business. Oh and let's not forget the Zine, or music and scene magazines that were so popular in the era that saw photocopying come down in price. HyperCard made for a pretty sweet Zine. HyperCard sprang from a trip when the graphical interface was still just coming into its own. Digital computing might have been 40 years old but the information theorists and engineers hadn't been as interested in making things easy to use. They wouldn't have been against it, but they weren't trying to appeal to regular humans. Apple was, and still is. The success of HyperCard seems to have taken everyone by surprise. Apple sold the last copy in 2004, but the legacy lives on. Successful products help to mass- Its success made a huge impact at that time as well on the upcoming technology. Its popularity declined in the mid-1990s and it died quietly when Apple sold its last copy in 2004. But it surely left a legacy that has inspired many - especially old-school Apple programmers, in today's “there's an app for that” world.
More Than Just Code podcast - iOS and Swift development, news and advice
A re-roll of our WWDC 2019 episode - We are joined by Alexis Gallagher and Ricky de Laveaga in the Podcast Studio at WWDC 2019 McEnery Convention Center. Recorded at 11 am Friday June 7, 2019. We fact check on Bobby Orr and the approximate number of active iOS developers. #askMTJC has Namrata Bandekar responding to joining start ups, as well the pronunciation of Dave Verwer IRL. We discuss our impressions of WWDC 2019 — SwiftUI, declarative programing, Combine framework, ARKit 3, Reality Composer, Swift Playgrounds 3, Swift Package Manager, stand alone Watch apps, iPadOS, TestFlight Feedback, Transporter, and Sign In With Apple. Picks: Performance, Pencil Support, Optimizing File Storage, DataFlow for SwiftUI, Combine in Practice, Sign In With Apple, Voice Dream Scanner, ClassKit, What's New In Swift, try! Swift, AltConf. Special Guests: Alexis Gallagher and Ricky de Laveaga.
Steve Jobs had an infamous split with the board of directors of Apple and left the company shortly after the release of the original Mac. He was an innovator who at 21 years old had started Apple in the garage with Steve Wozniak and at 30 years old while already plenty wealthy felt he still had more to give and do. We can say a lot of things about him but he was arguably one of the best product managers ever. He told Apple he'd be taking some “low-level staffers” and ended up taking Rich Page, Bud Tribble, Dan'l Lewin, George Crow, and Susan Barnes to be the CFO. They also took Susan Kare and Joanna Hoffman. had their eyes on a computer that was specifically targeting higher education. They wanted to build computers for researchers and universities. Companies like CDC and Data General had done well in Universities. The team knew there was a niche that could be carved out there. There were some gaps with the Mac that made it a hard sell in research environments. Computer scientists needed object-oriented programming and protected memory. Having seen the work at PARC on object-oriented languages, Jobs knew the power and future-proof approach. Unix System V had branched a number of times and it was a bit more of a red ocean than I think they realized. But Jobs put up $7 million of his own money to found NeXT Computer. He'd add another $5 million and Ross Perot would add another $20 million. The pay bands were one of the most straight-forward of any startup ever founded. The senior staff made $75,000 and everyone else got $50,000. Simple. Ironically, so soon after the 1984 Super Bowl ad where Jobs based IBM, they hired the man who designed the IBM logo, Paul Rand, to design a logo for NeXT. They paid him $100,000 flat. Imagine the phone call when Jobs called IBM to get them to release Rand from a conflict of interest in working with them. They released the first computer in 1988. The NeXT Computer, as it was called, was expensive for the day, coming in at $6,500. It sported a Motorola 68030 CPU and clocked in at a whopping 25 MHz. And it came with a special operating system called NeXTSTEP. NeXTSTEP was based on the Mach kernel with some of the source code coming from BSD. If we go back a little, Unix was started at Bell Labs in 1969 and by the late 70s had been forked from Unix System V to BSD, Unix version 7, and PWB - with each of those resulting in other forks that would eventually become OpenBSD, SunOS, NetBSD, Solaris, HP-UX, Linux, AIX, and countless others. Mach was developed at Carnegie Mellon University and is one of the earliest microkernels. For Mach, Richard Rashid (who would later found Microsoft Research) and Avie Tevanian, were looking specifically to distributed computing. And the Mach project was kicked off in 1985, the same year Jobs left Apple. Mach was backwards-compatible to BSD 4.2 and so could run a pretty wide variety of software. It allowed for threads, or units of execution and tasks or objects that enabled threads. It provided support for messages, which for object oriented languages are typed data objects that fall outside the scope of tasks and threads and then a protected message queue, to manage the messages between tasks and rights of access. They stood it up on a DEC VAX and released it publicly in 1987. Here's the thing, Unix licensing from Bell Labs was causing problems. So it was important to everyone that the license be open. And this would be important to NeXT as well. NeXT needed a next-generation operating system and so Avi Tevanian was recruited to join NeXT as the Vice President of Software Engineering. There, he designed NeXTSTEP with a handful of engineers. The computers had custom boards and were fast. And they were a sleek black like nothing I'd seen before. But Bill Gates was not impressed claiming that “If you want black, I'll get you a can of paint.” But some people loved the machines and especially some of the tools NeXT developed for programmers. They got a factory to produce the machines and it only needed to crank out 100 a month as opposed to the thousands it was built to produce. In other words, the price tag was keeping universities from buying the machines. So they pivoted a little. They went up-market with the NeXTcube in 1990, which ran NeXTSTEP, OPENSTEP, or NetBSD and came with the Motorola 68040 CPU. This came machine in at $8,000 to almost $16,000. It came with a hard drive. For the lower end of the market they also released the NeXTstation in 1990, which shipped for just shy of $5,000. The new models helped but by 1991 they had to lay off 5 percent of the company and another 280 by 1993. That's when the hardware side got sold to Canon so NeXT could focus exclusively on NeXTSTEP. That is, until they got acquired by Apple in 1997. By the end, they'd sold around 50,000 computers. Apple bought NeXT for $429 million and 1.5 million shares of Apple stock, trading at 22 cents at the time, which was trading at $17 a share so worth another $25 and a half million dollars. That makes the deal worth $454 million or $9,080 per machine NeXT had ever built. But it wasn't about the computer business, which had already been spun down. It was about Jobs and getting a multi-tasking, object-oriented, powerhouse of an operating system, the grandparent of OS X - and the derivative macOS, iOS, iPadOS, watchOS, and tvOS forks. The work done at NeXT has had a long-term impact on the computer industry as a whole. For one, the spinning pinwheel on a Mac. And the Dock. And the App Store. And Objective-C. But also Interface Builder as an IDE was revolutionary. Today we use Xcode. But many of the components go back all the way. And so much more. After the acquisition, NeXT became Mac OS X Server in 1999 and by 2001 was Mac OS X. The rest there is history. But the legacy of the platform is considerable. Just on NeXTSTEP we had a few pretty massive successes. Tim Berners-Lee developed the first web browser WorldWideWeb on NeXTSTEP for a NeXT . Other browsers for other platforms would come but his work became the web as we know it today. The machine he developed the web on is now on display at the National Museum of Science and Media in the UK. We also got games like Quake, Heretic, Stife, and Doom from Interface Builder. And webobjects. And the people. Tevanian came with NeXT to Apple as the Senior Vice President of Software Engineering. Jobs became an advisor, then CEO. Craig Federighi came with the acquisition as well - now Apple's VP of software engineering. And I know dozens of others who came in from NeXT and helped reshape the culture at Apple. Next.com still redirects to Apple.com. It took three years to ship that first computer at NeXT. It took 2 1/2 years to develop the iPhone. The Apple II, iPod, iPad, and first iMac were much less. Nearly 5 years for the original Mac. Some things take a little more time to flush out than others. Some need the price of components or new components to show up before you know it can be insanely great. Some need false starts like the Steve Jobs Steve Jobs famously said Apple wanted to create a computer in a book in 1983. That finally came out with the release of the iPad in 2010, 27 years later. And so the final component of the Apple acquisition of NeXT to mention is Steve Jobs himself. He didn't initially come in. He'd just become a billionaire off Pixar and was doing pretty darn well. His arrival back at Apple signified the end of a long draught for the company and all those products we mentioned and the iTunes music store and the App Store (both initially built on WebObjects) would change the way we consume content forever. His impact was substantial. For one, after factoring stock splits, the company might still be trading at .22 cents a share, which is what it would be today with all that. Instead they're the most highly valued company in the world. But that pales in comparison to the way he and his teams and that relentless eye to product and design has actually changed the world. And the way his perspectives on privacy help protect us today, long after he passed. The heroes journey (as described is a storytelling template that follows a hero from disgrace, to learn the mistakes of their past and reinvent themselves amidst a crisis throughout a grand adventure, and return home transformed. NeXT and Pixar represent part of that journey here. Which makes me wonder: what is my own Monomyth? Where will I return to? What is or was my abyss? These can be large or small. And while very few people in the world will have one like Steve Jobs did, we should all reflect on ours and learn from them. And yes that was plural because life is not so simple that there is one. The past, and our understanding of it, predicts the future. Good luck on your journey.
Shownotes We hebben deze keer de eer om Jeroen Leenarts te gast te hebben. Jeroen is een zeer ervaren iOS developer, en hij vertelt ons in deze aflevering wat dat allemaal behelst. Jeroen is sinds 2002 actief als software ontwikkelaar en heeft in die rol met veel verschillende technologiën en stacks gewerkt. Een special shout out gaat naar Salves, zij hebben het mogelijk gemaakt dat we deze aflevering online hebben kunnen opnemen via Zencastr. En we hebben sinds kort ook de CodeKlets Nieuwsbrief. Een tweewekelijkse nieuwsbrief met interessante links naar zaken die developers interessant vinden met een klein beetje duiding op zijn CodeKlets'. Met hosts Bernard Kroes - LinkedIn Saber Karmous - LinkedIn Twitter Jeroen Leenarts Twitter - @leenarts LinkedIn - link leenarts.net Jeroens eigen podcast! - De AppForce1 Podcast Xcode shortcuts blogpost van Jeroen CocoaHeadsNL Onderwerpen 00:00:35 Intro 00:23:13 Hoe gaat het bouwen van een iOS app? 00:25:51 Het verschil tussen Swift & Objective-C 00:30:18 UI bouwen in code of met de Interface Builder? 00:36:49 Wat is ABI compatibiliteit? 00:45:57 Hoe hou je rekening met security in een app? 00:55:50 Wat is Cocoa? 01:25:02 Twitter rant die geen rant was 01:31:49 Developer Dilemma's 01:42:55 Tips 01:46:45 Outro Show links Pragmatic Progammer, 20th Anniversary Edition Podcast over hoe je meer salaris krijgt als iOS dev Big Nerd Ranch boeken Getting started met iOS development tutorial van Apple zelf Objective-C Swift Watchmen Watchmen HBO Serie Alan Moore Alan Moore / Providence CodeKlets links CodeKlets CodeKlets Nieuwsbrief CodeKlets Slack CodeKlets Twitter
More Than Just Code podcast - iOS and Swift development, news and advice
Starting with our initial reactions at WWDC to our latest trials, we re-visit SwiftUI. Apple Swift UI Tutorials. Incorporating SwiftUI's Principles in All Your Code. 3 Steps to Prepare Your Apps for SwiftUI, Combine, iPadOS, Project Catalyst, and Any Other Leaps in the iOS Industry. Understanding @State in SwiftUI. [Fracking] SwiftUI - Everything you need to know to adopt SwiftUI. SwiftUI Essentials: Creating and Combining Views. The Swift Behind SwiftUI. SwiftUI Changes. Advanced SwiftUI Transitions. Swift Playgrounds for iPad now supports swift 5.1, iOS 23 SDK, SwiftUI & Combine. PenBook built with SwiftUI, PencilKit and iPadOS. A SwiftUI Kickstart . SwiftUI Cheat Sheet. SwiftUI Layout System. Interface builder with SwiftUI properties. SwiftUI Views book. 7 Awesome Open Source SwiftUI Projects To Inspire You. Why I quit using the ObservableObject in SwiftUI. Gosh Darn SwiftUI (updated). Mark on UIRepresentable. Special Guests: Alexis Gallagher, Mike Vinakmens, and Ricky de Laveaga.
More Than Just Code podcast - iOS and Swift development, news and advice
Recorded LIVE during WWDC 2019: In this special episode Tim interviewed several iOS developers on-site at WWDC thought the conference. Joining us this week are Tom Harington, Jeff Rames, Ish Shabazz, Kilo Loco, Mark Struzinzki, Adam Armstrong, Dru Freeman, Ray Fix, Megan Winter, Anthony Laurence, Ricky de Laveaga, Kendal Gelner, and literally on the street Joe Cieplinski. We discuss the WWDC Keynote, PSotU, SwiftUI, Project Catalyst, Dark Mode, stand alone Watch Apps, Xcode 11, Voice Control, iPadOS, Swift Package Manager, the 2019 Mac Pro, Pro Display XDR, The Talk Show, Micro.blog, Embrace.io, AltConf, Swift Playgrounds 3, Xcode 11, and the Release Notes Conference. Special Guests: Aᴅᴀᴍ Aʀᴍsᴛʀᴏɴɢ, Anthony Laurence, Dru Freeman, Ish, Jeff Rames, Joe Cieplinski, Kendall Gelner, Kilo Loco, Mark Struzinski, Meg Winter, Ray Fix, Ricky de Laveaga, and Tom Harrington.
More Than Just Code podcast - iOS and Swift development, news and advice
We are joined by Alexis Gallagher and Ricky de Laveaga in the Podcast Studio at WWDC 2019 McEnery Convention Center. Recorded at 11 am Friday June 7, 2019. We fact check on Bobby Orr and the approximate number of active iOS developers. #askMTJC has Namrata Bandekar responding to joining start ups, as well the pronunciation of Dave Verwer IRL. We discuss our impressions of WWDC 2019 — SwiftUI, declarative programing, Combine framework, ARKit 3, Reality Composer, Swift Playgrounds 3, Swift Package Manager, stand alone Watch apps, iPadOS, TestFlight Feedback, Transporter, and Sign In With Apple. Picks: Performance, Pencil Support, Optimizing File Storage, DataFlow for SwiftUI, Combine in Practice, Sign In With Apple, Voice Dream Scanner, ClassKit, What's New In Swift, try! Swift, AltConf. Special Guests: Alexis Gallagher and Ricky de Laveaga.
More Than Just Code podcast - iOS and Swift development, news and advice
Recorded LIVE during WWDC 2019: In this special episode Tim interviewed several iOS developers on-site at WWDC thought the conference. Joining us this week are Tom Harington, Jeff Rames, Ish Shabazz, Kylo Loco, Mark Struzinzki, Adam Armstrong, Dru Freeman, Ray Fix, Megan Winter, Anthony Laurence, Ricky de Laveaga, Kendal Gelner, and literally on the street Joe Cieplinski. We discuss the WWDC Keynote, PSotU, SwiftUI, Project Catalyst, Dark Mode, stand alone Watch Apps, Xcode 11, Voice Control, iPadOS, Swift Package Manager, the 2019 Mac Pro, Pro Display XDR, The Talk Show, Micro.blog, Embrace.io, AltConf, Swift Playgrounds 3, Xcode 11, and the Release Notes Conference. Special Guests: Anthony Laurence, Dru Freeman, Joe Cieplinski, Kendall Gelner, Kilo Loco, Meg Winter, Ray Fix, and Ricky de Laveaga.
More Than Just Code podcast - iOS and Swift development, news and advice
We are joined by Alexis Gallagher and Ricky de Laveaga in the Podcast Studio at WWDC 2019 McEnery Convention Center. Recorded at 11 am Friday June 7, 2019. We fact check on Bobby Orr and the approximate number of active iOS developers. #askMTJC has Namrata Bandekar responding to joining start ups, as well the pronunciation of Dave Verwer IRL. We discuss our impressions of WWDC 2019 — SwiftUI, declarative programing, Combine framework, ARKit 3, Reality Composer, Swift Playgrounds 3, Swift Package Manager, stand alone Watch apps, iPadOS, TestFlight Feedback, Transporter, and Sign In With Apple. Picks: Performance, Pencil Support, Optimizing File Storage, DataFlow for SwiftUI, Combine in Practice, Sign In With Apple, Voice Dream Scanner, ClassKit, What's New In Swift, try! Swift, AltConf. Special Guests: Alexis Gallagher and Ricky de Laveaga.
In this episode of The Frontside Podcast, panelists Charles Lowell, Rob DeLuca, and Sam Keathley, discuss how much the distinction between frontend, backend, and fullstack developers matter in both personal and professional senses. The differences in mindset between these categories are also discussed, for example, how does a fullstack developer solve a problem vs how a backend or frontend developer? And also, how clear (or fuzzy) is the line that separates them? What are the skills a frontend or backend developer needs to consider themselves fully fullstack? And finally, is there any sort of tribal separation between the factions? Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at contact@frontside.io or on Twitter at @thefrontside. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 101. My name is Charles Lowell. I'm a developer here at The Frontside and I'll be hosting today's episode. Today we're going to be talking about the different developer profiles that are out there. You might have heard mention of them on Stack Overflow, on job boards, on the Twitterverse. Things like frontend, backend, full stack, half stack, short stack. [Chuckles] Things like that. With me to talk about these are Rob and Sam. Rob is our director of open source here at Frontside and Sam is a software engineer here at Frontside. So, hey y'all. SAM: Hey. ROB: Hey yo. CHARLES: Alright. So, before we get into the meat of the topic, there are a few announcements that we wanted to make. First and foremost, this is some really exciting news. This week, Taras Mankovski officially joined the team at The Frontside. And we are really, really excited about that. [Cheers] ROB: That's exciting. CHARLES: Yeah. It's super exciting. Not only is Taras an exceptional engineer, he's got amazing code skills. He's extremely empathetic and a great person to work with. He's great working with clients and he's also fantastic at really working with developers who are climbing that ladder and helping them level up. So, he's been involved in mentorship literally since I've known him. I think that was the first time that we ever came into contact with him was through his mentorship work in the Ember community. And we've been collaborating with him for years on several open source projects. And so, we just are so excited and know that he's going to come on and do some amazing things by helping us be better developers, helping us be better community emissaries. And so, lots of good stuff coming out of that. ROB: Absolutely. CHARLES: Yeah, yeah. No, that's really exciting. So, definitely wanted to throw that out there. ROB: Too bad he didn't join a little bit earlier. We would have had a good time with him on this podcast. CHARLES: I know. Well he's actually, I think he's been on the podcast twice. ROB: [Laughs] That's true. CHARLES: But yeah, there's definitely a couple of topics where his input would have been absolutely critical. I think it would have been great to have him along when we were trying to run our own apprenticeship programs. Those would have worked out I think a lot better. Well, not to say that the outcomes haven't been stellar in some cases. But I think having his expertise would have made it a lot smoother. That said, before we jump in then, just wanted to let everyone know that as always, if you want to work with us you can get to us at contact@frontside.io or send a shout-out on Twitter @TheFrontside. Okay. Y'all, let's jump into it. Like what is even a stack? ROB: [Laughs] So, do you want to kind of set up where this came from, Charles? I think it came from you and I going back and forth on Twitter. And I was like, “You know what? We need to talk about this on the podcast.” CHARLES: Yeah. I think I was actually on vacation. ROB: [Laughs] That's right. You were trying to ski. CHARLES: [Laughs] I was on the ski lift. And I saw you tweeting and I was like, “No, no, no. I got to respond to that.” Probably because there was maybe a little bit of disagreement but also because I just needed something to do. Looking out the majestic scenery of the Rocky Mountains wasn't enough. So yeah, what's the backstory there? ROB: So, I can't remember what I was actually tweeting about. But I kind of feel like there is a distinction between a frontend developer, a backend developer, and at this point I don't know if a full stack developer truly exists. I mean, it does. But it's used more often than it really implies what they're doing. Usually when you hear of a full stack developer, it's like, “Man, I can sling some code on the backend and I can do a little bit of architecture stuff on the frontend. But CSS, keep that away from me.” And in my opinion, if you're a full stack developer, you need to sling CSS, too. CHARLES: Really? ROB: Yeah. CHARLES: No, no. I certainly agree. Because I was going to ask, is it fair to say that full stack developer is code for like, startup developer? ROB: Yeah. That's a good – like a utilitarian, like a jack of all trades but not a master of any? CHARLES: Right, exactly. ROB: I can take that. So, I guess the way we can start to dig into this one is like, how much distinction is there between a frontend, a backend, and a full stack developer? And does that matter in a professional sense? CHARLES: Right. And so, I think my take was that the skillsets that you need in both places are actually much more convergent than you think, than people might think. In other words, the skills that you utilize on the backend actually translate very well to the frontend. I think my stance is that what makes a frontend developer and a backend developer is more the problem sets that you gravitate towards naturally, the things that interest you. I actually was a backend developer. And now I consider myself to be primarily a frontend developer. But the skills that I had developed writing backend systems in Java translated shockingly well into frontend development with JavaScript. But it was working on the portion of the program that interfaced with the human was, that was the thing that fascinated me. And so, it's what I gravitated towards. And so, I guess in my [6:15 inaudible] or the way that I have been thinking about it is that what makes a frontend developer and a backend developer is more what gravitational pulls you respond to, rather than one particular skillset. But I know that you've got a perhaps more refined take on that, or a different take. ROB: Yeah. Before I do, I want to know what Sam's thoughts are on this. This would be a good one. SAM: Where I come from in the understanding of frontend, backend, and full stack is I – background on me: I did a bootcamp before working here. So, I did a development bootcamp where they were really excited to tell you at the end of it that, “Oh, you're a full stack developer because we've introduced you to everything. Like, touched on every sort of little topic. You're full stack. Tell everyone you're full stack.” And it's like, “Well, you're not really a specialist in any of the sense.” So, what makes a difference to me, I'm going to specifically talk about full stack, but it's like before you can say you're full stack, having knowledge of frontend and at backend, you need to have expertise in at least one of them first, or understanding of that mindset first. Like if I say that I like frontend work more then I need to understand frontend work more before I can say that I understand backend work, you know? ROB: Yeah. CHARLES: So, do you feel like the bootcamp was doing you a disservice? Or do you think they got… SAM: I don't think they did a disservice at all. So, they did a really good job. So, bootcamps are really for introducing you to everything. And then whatever you take from that is your own. So, they introduce you to all the little things like database working and then JavaScript, Ruby, whatever it is. And then it's your job to figure out in those introductions, what you resonate most with. So, I think they did a really good job in that. I think that they shouldn't tell you what you are, like tell you that because they touched on whatever it was, that you're full stack. CHARLES: Right. SAM: So, I don't think they did a disservice at all. I learned a lot. But I wouldn't say I'm full stack at all. CHARLES: So, if you feel as though you're not full stack, what do you feel that you are? SAM: Definitely frontend. CHARLES: Definitely frontend. SAM: I gravitate more towards frontend. ROB: Why would you feel that way? Is it because you're more pulled towards the UI of things? Or is that where you feel like you've gotten most of your experience now? SAM: Actually a little bit of both. I tend to like the UI of things a little bit more. It's interesting. Whenever I was going to the bootcamp, I thought I was going to be more backend because I thought I really like working with the behind the scenes sort of. You don't see this work but you know it's there. But I definitely like the UI of frontend a lot more. Just personal. ROB: I see that. SAM: And it's where my skillset is, because this is all frontend work that I'm doing here at The Frontside. So, it's what I know most at this point. CHARLES: Yeah. I'm curious too. Isn't it true that there's also a conception in the wider tech world that frontend is limited to CSS and HTML? ROB: Ooh. Yeah, that could be. CHARLES: Like when you see job posting for frontend developers, typically it's like, we want someone… ROB: Yeah. It's kind of morphed from – JavaScript developer is now a single-page app developer instead of frontend. Yeah. Yeah, I see what you're saying. It's now, it could be considered as HTML and CSS and not JavaScript anymore. [Chuckles] CHARLES: Which is so bizarre to me. SAM: [9:42 inaudible] a lot of places when a frontend developer who is also a UX designer. Someone who has the knowledge of designing things from the ground up and then only working in things that look good, rather than logic. ROB: Yeah. This can be probably an entirely other topic. But that's like the frontend of the frontend and the backend of the frontend, is like [10:03 inaudible] call it. Because there are [10:06 inaudible] developers. And single-page apps have gotten so complex these days, between your data layer and your testing and managing state on the frontend. There is a backend, an architecture, that you need to consider when you're developing a single-page app. And I've worked on teams where there are developers that are working on the frontend but they still don't like CSS. They don't do CSS things and they don't consider layout or any design. They just take the ticket and they get the data going. Get the data from the server, request it, display it on the page. And then another person would come through and style it up to the spec or the mock. But yeah, that's interesting. So for my take on this, and where this actually really came from, is we were going through some hiring. And we were trying to figure out how we can place somebody or hire someone that can be effective in the role that we immediately needed. And all of our immediate needs were in frontend-specific things. And we can actually talk about if they're frontend-frontend or frontend of the backend. But where this kind of came from or was born was: if we're hiring somebody that needs to fill a frontend role and they're primarily a backend developer, there are gotchas and things you have to know to be an effective frontend developer. Like quirky browser things that happen or like how to set up a Babel transpilation setup. And what are the gotchas here? Kind of the history of the frontend web, because there's a lot of things that are there that can cause a lot of headache if you don't know the backstory. And I know from your perspective Charles, you think – and this is isn't wrong – but you think that if somebody has a really talented backend developer, it's really just concepts that you can apply to the frontend. And I agree with that. CHARLES: Right. But you have to want to do it. [Laughs] ROB: Yes. That is also a key. CHARLES: You have to be gripped by the problem set of the frontend. You want it to inspire you to leverage those solutions. ROB: Yeah. So, would you say there's a different mindset between a frontend, backend developer, and full stack? Does a full stack developer solve a problem that's different from how a backend developer or a frontend developer would? CHARLES: That's a subtle question and probably one that might offend people, my answer to it. So, I'll go ahead and answer it. [Chuckles] ROB: Hashtag [12:23 inaudible] CHARLES: Actually, maybe not. Just in my experience historically – I want to underline the fact historically – I think that it is people who gravitate towards the outside-in mindset, in other words the very first thing they're thinking of is, “How is this going to feel to a person who's going to use this?” If that's your first question that you ask, then you probably are going to gravitate towards the frontend. Then in terms of the backend, I'd say historically – and like I said, I want to underline that, and I'll get to that later – I think it's people who are more drawn to: I want to attack the most complex problem that exists. Like distributing state over 10,000 nodes, managing huge deployment infrastructures that drive these massive websites that happen at this mind-boggling scale. And so, there you really are thinking computer to computer and, “What's the ideal interface for doing that?” And then on the frontend you're thinking more like human to computer, because that's where the interface lies. Now the reason I say… ROB: I feel so let down. Where's the controversy? CHARLES: Well, okay. Well, because I think that basically – I think the controversy is saying like people who are more naturally empathetic. I don't know. That would be the controversy thing. But I want to say historical. ROB: Yeah. I can see that. [Laughs] CHARLES: So, I want to say historical too, because I feel like one of the things that's been magical about the last two decades of software development is the dawning realization that no software you write exists in a vacuum and that it's all interconnected. And so, I think that I for example feel very strongly while I try to think about the user experience first. And the developer, I'm also thinking about developer experience first. The way that you want a system to feel is going to inform the design of the UX workflow and that's going to affect the architecture of your frontend. And if you're interfacing with it through different media, like websites, phone, I don't know, even text messages, Slack, what have you – that's going to inform then the next level of how your APIs are shaped, your public-facing APIs. Which then inform the structure of your internal deployments. So, recognizing that the decisions you make in one end of the stack and ripple through completely and that they're not what we hold as dear these concepts of separation of concerns and complete and total isolation of layers. That really is false. But what it does is it enables us to change the individual layers to more – ironically the reason you want to have separation of the layers is so that it more easily lets you change them provide a more integrated experience. So, I think that's a long way of saying that I think frontend developers are more aware of what's going on in the backend and that they might be drawn into the backend. And the same thing goes for backend developers, realizing that the decisions they make are affected by the frontend and affect the frontend. And so, I think there's been a dawning more of a collective responsibility for design, for operations, for developer experience. And I think it's great. ROB: Yeah. And to [think back off] that. So, I was kind of wondering where the controversy was, because that's kind of my exact answer, too. Where do you gravitate towards on? The difference of mindset is like, if you've got a problem and let's say you're a full stack developer, so whatever that manes, but if you're given a task where you have to implement the frontend and the backend, where you gravitate towards first I would say is how you would attack solving a problem. For me, I would immediately go to the frontend and see how a user would immediately interact with it and then work out that way. Mostly also because I like having a tight feedback loop. And the frontend provides that nicely. I can change something and immediately see the difference there. And in the backend you can spend a little bit of time, unless you're TDD which you should be – you can spend a little bit of time piecing together things and figuring out the architecture. And then you'll have something that you could show for. It's just nice to see UI get thrown on the page. And it's real and you click a button and something happens. That's a really nice feeling. And that's kind of where I gravitate towards. And if yeah, if I had to attack the problem, I'm going there first. I get the endorphins from it. [Chuckles] CHARLES: Right. So, if we want to add controversy to the other side, because you got to always be controversial, right? So, we said the really blunt horrible oversimplification is that people who are more naturally empathetic gravitate towards the frontend. You could also say that from the other perspective, people who are more internally validated will gravitate to the backend. Because if you need to get those endorphins from working on the frontend, basically what you're saying is, “I want to put it in front of people and get the feedback from those people and know whether it's good or bad.” Whereas you could say, “Actually, I don't need validation from other people. I've got this concept of this architecture that is going to be the ideal thing. I know it. I've got this vision and I'm going to chase it, regardless of what's going on.” I think you can more readily do that on the backend because you're not as open to the feedback of a whole bunch of different users. And like I said, I think those are gross oversimplifications. ROB: Yeah. I agree. And so, as a devil's advocate towards the backend developer that is less empathetic, I think actually some of the best backend developers I've ever worked with were the most empathetic people ever. Because they know that software is for humans. And humans are going to be consuming the API that they build. And they take that into consideration. CHARLES: Absolutely. And I actually think that empathy pervades good software development just wherever you find it. Because yeah, someone's going to be using your APIs whether it's software as a service or it's a library. If it's software as a service, it's got to be easy to work with. It's got to be performant. It's got to have a nice command line. And so, you have to be thinking at all times, “What is it like to use this software? What is it like to consume it? What is it like to link it into my library? What is it like to call it from a web client?” So yeah, I think you're absolutely right. I think it's actually one of the great virtues of great software developers. SAM: Yeah. So, something that I've always kind fo had a question with, especially coming from that bootcamp setting: is there any sort of tribal separation between what you would consider a frontend or a backend developer or even full stack? Like, “I'm better because I understand data layers than I understand how a button fits on a page,” that sort of thing. CHARLES: I would say absolutely yes. If you at the, just do a quick poll of the Twitterverse, it seems like people tend to hang out in little circles of similar interest. So, there's definitely a bunch of people that I follow that are always tweeting about backend stuff. ROB: Yeah. Twitter is ‘build your own echo chamber'. CHARLES: Yeah. And there are people who I follow that are tweeting nothing but mostly frontend – when I say frontend, I mean frontend of the frontend. Well basically, from CSS down to nothing deeper than React components. And then there's people who are talking primarily about the backend of the frontend. So yeah, I do think that people – there are clearly, there are different areas of the stack and I think that people do tribalize around them. So, the question is: Who are the border agents? Because always cross-border trade. Any time you have borders, there's an exchange of ideas and information and things that happen at those layers. And actually, one of the things I'm really curious about is: How does that happen? ROB: Yeah. You might have the best perspective on this because you did – you were using Java Swing back in the early 2000s building UI. And that's like backend things. And then you had a lot of experience with Rails and you've moved into the JavaScript world. And the thing that I've noticed with frontend is, we're applying a lot of concepts that existed on the backend. And we're moving all that complexity into the frontend. And that's kind of where that fuzzy line of, “Are you the frontend of the frontend? Are you the backend of the frontend?” comes from. And it's interesting that – like this is going to be another podcast. We'll end up talking about this – but we have – MVC lives on the frontend. Like in React, your C is a container component. The controller is a container component. The model is probably your Redux layer if you have it or if you're using micro-states. And the view is your components, your view layer components that you're rendering down. So, these concepts are moving from the backend to the frontend. We're just kind of renaming them and making them our own concept. But they're there. So, how does that knowledge sharing happen? Is it really just a mass exodus of backend developers interested in frontend developers now? CHARLES: I don't know. I think it goes both ways. So, I can only speak to my own experience. And that was when I first started doing frontend development was back in 2003 I think. So almost 15 years ago. We were building a touchscreen interface for an electronics vendor in the UK. And it was just so much fun, because we were getting to build these interfaces that literally looked like nothing else. And you could touch them and you had support for rudimentary gestures and there was no keyboard. And basically the only interface was your fingers and like a price scanning gun. And everything, all the entire UI had to be developed out of that. And so, it was such a novel system and it was so fun to implement that I just gravitated towards it. I think the thing that was particularly compelling was it was very interactive UI. It was high-touch, literally. This is a clerk who's sitting there using this thing as rapidly as they can to sell stuff and move people through the line. So, it was like a unique problem. But the thing that was cool about it was I realized so many – we kind of already touched on this in this conversation – so many things that I had learned on the backend applied there. And there was in order to provide that experience, there had to be a pretty complex machine behind it. And that was fascinating, that machine. And so, we were able to apply a lot of the concepts. And so, in that time on the backend I'd just come off working off a backend that had basically an event bus – we would probably call them microservices now, although we didn't call them that then – were coordinating based on all these events. And that translated over into the frontend really, really well. And I remember using a lot of the techniques for exception handling – doing it on the frontend and doing a lot of the multithreaded stuff that we were doing on the backend, trying to reconcile that with the frontend and really understanding. So, there were all these analogous concepts. And it could be – so, there was an original exodus of backend development, for me personally. And so for me, it was like I felt like I moved onto the web pretty much exclusively in 2006. And it was a good – I would say 2013 maybe is when web UI development finally caught up with Java Swing. Like it was like, that whole time I was like, “I'm using the web because it's an awesome deployment platform. And it's got all this great stuff,” but man, the developer experience is not as good as like a stateful fat GUI was back then. And now, I would say it's actually surpassed quite significantly. But now, I think there are a lot of people maybe who either – I think there's a casting back of people who are in frontend development and casting back to the web. So right now, my love affair with immutability and functional programming started by using a Clojure web framework which borrowed a lot of the ideas from Clojure. So, I guess there was an exodus there – people from Clojure wanting to develop apps, wanted to have their goodies. But then I found that and I was like, “Whoa, that's awesome.” But then that really set the hook for me. And so now, I try and go back to the well, the backend well or the shared computational well, as much as I can. So, all of that stuff of basically discovering all this functional programming stuff, this highly formalized functional programming, all came from saying, “Wow. I got a taste of that. Let me get more.” So, it's very much like trying to run through the village of the backend and ransack the stores and take as much as I can and bring it back, because I know that it's good. ROB: So earlier in the podcast, you said that you were a frontend developer. You described yourself as a frontend developer. And that's funny, because I actually consider you a full stack developer. It's because you can jump in on the backend and sling any kind of code as well as anybody could, and then you can also do the same thing on the frontend. So, the question I have here is: Do you think actually someone that truly is a full stack developer – and we can define that in a second – but do you think they're at an advantage here, because they have all that experience? You can answer yes. But why? Why do you think they have an advantage? CHARLES: I think they have an advantage in the same way that a person who's bilingual has an advantage. So, if you are living in North America, it behooves you to speak Spanish because you are now open to an entire set of markets that were previously closed to you. Well, not entirely closed but like you can trade with Mexico and you can trade with South America. You can buy and sell goods. You have access to yeah, emerging technologies that might – something special might be happening in Mexico City, or in Medellín, Colombia, and you're going to have first access to that. And so, if you don't, if you're not bilingual, then you're going to have to go through an intermediary who is. And so, there's a premium: you get to be the middle man so to speak. Or you get to be, maybe that has kind of a negative connotation, but you get to be the broker of new ideas and new technologies. If you can, if you are fluent in backend so to speak, then you can go into backend-landia and you can talk with the developers there and see what kind of cool stuff they're doing. And then you can take it across the border into frontend-land and sell it. And so, that's – I think we're very much first to the gun on – not first to the gun but we're ahead of the pack in terms of functional programming. Because we've seen that. We've seen it proved out and we've now actually started to integrate it into your day-to-day routines. And we're ahead of the pack on that, right? And so, I think that's kind of a keystone analogy for me that I think really, really captures what is the advantage in being a full stack engineer. ROB: So, well how do you define a full stack engineer or developer? What things do you have to possess to actually claim that title? In order to be a full stack developer I personally believe you have to know, you have to be comfortable with CSS. You can hate it. You can yell at it. But I think you have to be able to put together a layout if a designer gives you a comp in order to claim full stack. And in the same token, if you're a full stack developer and you mainly came from the frontend, you should be able to implement backend features. I don't actually have – so, I'm strong in the frontend, not so strong in the backend. What would be the analogous of CSS in the backend? Would it be like mocking your controller actions? [Chuckles] CHARLES: I would say you should have a familiarity with HTTP and REST, would probably be the equivalent. Kind of like a foundational technology that just every single technology is oriented around it, or most. Regardless of the protocol you're using – there are things like GraphQL which are not really RESTful, although it's a blurry line there – but they're still delivered over HTTP. And so, understanding things like CORS, understanding the things that are going to be universal to APIs. ROB: I think a lot of people try to claim full stack. I try to claim it. And I know I'm not. I can put together a pretty crummy Rails API on my own for personal projects. But I'm not going to be the one that's setting up indexes on a database to optimize a database or anything. I think that does come in time, but you have – borrowing from Brandon Haye's talks about career development – if you're a full stack developer, I think you end up having to be in the industry for a long time. Longer than what we consider a senior developer these days, I think. Because you could be a senior developer and be specialized. And we see that all the time, and that's okay. But in order to amass that knowledge and experience, I think you have to be in the industry for a long time and done those things a couple of times to really know. CHARLES: Yeah. I agree. So, can I add something there? To continue the analogy of being full stack is like being bilingual or multilingual. I go back to those analogies a lot because that's what I – linguistics is what I studied in school. But when I was studying linguistics, one of the things that was going on there was they were kind of redefining what… ROB: That makes so much more sense of your vocabulary. [Laughs] CHARLES: What it means to be bilingual. There was kind of a reorientation of that definition that was going on while I was in school. And that was being bilingual doesn't necessarily mean you're able to converse about poetry or like deep technology or give speeches in another language. It really is, it's as spectrum of… ROB: Ooh, that's quite interesting. CHARLES: The definition of bilingual is like: Do you use another language in your life? So, if you are let's say someone who is a recent immigrant to a country and let's say you've got less than 1,000 words but you're using them to buy groceries, to pay bills, to do things like that, then you are bilingual. Bilinguility is not an exclusive club. It's really, are you actually using a language? So, if… ROB: Ooh, so that actually gets my wheels turning. Does that mean that you can have a junior full stack developer? Because like, if you just merely speak the both languages, technically by that definition, I jive with that. You can speak two languages. You are bilingual. You can write in two different languages. You might be full stack. But does that mean in the software industry you are a junior full stack developer and then as you go on and get tasks that are full-stack-like, you get better on both sides? Or is it as an industry, we really have to specialize? CHARLES: To start on the first point, I think that if you – let's just restrict it to one language – if you're doing JavaScript on the frontend and using Node.js on the backend, if you're writing Node code you are I would say by definition, and certainly by the definition of bilingual that I just proffered, you would be considered full stack, a junior full stack developer like I was saying. And I think that it's just been my experience that as you go on in your career, you will cross multiple layers of the stack just because you can't keep your hands off. If you have an ownership mentality of, “Here's this thing that needs fixed,” and it's on the backend, you know what? I'm going to go ahead and learn a little bit of how to do this, because I need it to work with the thing that I'm working on. ROB: Yeah, that makes sense. CHARLES: You will just naturally be drawn over borders throughout your career just because someone's got to do it, to do the thing that… ROB: You got to solve a problem. CHARLES: Right, when you've got to solve a problem. So, I think that people become more and more full stack over the course of their careers. But that said, I do think that there are clearly areas where functional specialization is absolutely a requirement. Like if you say, “You know what? We've got this API and we need to support 600 queries per second and we've got this huge, crazy deployment…” ROB: I will not be your person to do that. CHARLES: Yeah, exactly. That's something you're very much – that is something that you're very much hiring for. And you want to be hiring for like you said, someone who has the skill and someone who, that's what they want to do. ROB: Yeah. If you need better state management and rendering performance and testability on the frontend, I'm your person. [Chuckles] If you need me to scale your API, to handle hundreds of thousands of requests a second, nope. [Laughs] So yeah, I agree with the specialization. So Sam, I want to know. Has this conversation swayed you any way? Are you more interested in being full stack or are you leaning to a side more? [Chuckles] SAM: So, I think full stack is, it's as much about skillset as it is about personality. So, like you were talking a little bit earlier on how someone who's frontend might have more empathy towards the user. And someone who's backend might have more empathy towards the computer and the developer, rather than the end user. I think someone who's full stack has to have a wider range or empathy so they can empathize with all rather than just one or the other sets. I think personality-wise, I'd be a fine full stack developer. But I think professional-wise, I do gravitate towards the frontend because that's just how I am. As a person, I like to see the visual rather than the concept. I do a lot of painting. I do a lot of drawings. So, I'm a very visual person. So, it's really helpful to me, especially for someone who's junior and who's still learning and who came from that bootcamp experience, to be able to see what I'm changing. So, I think it does kind of go a little bit into experience as well. So, I think over time when I start touching on maybe some more backend work and I see some stuff that interests me, definitely I'll gravitate towards it, just because I want to learn. But I don't know that it's like an intrinsic quality, you would want to be full stack or be backend or be frontend, you know? ROB: That's interesting. Yeah, I agree with that. CHARLES: Yeah. That is actually a really interesting point. Because I think what I heard you say there is that when you have – software is a hidden world in many ways. You talked about it in the beginning of the conversation, the areas of the site unseen. Like you know it's there but it's hidden from view. So, there's a certain amount of vision that needs to develop. So, you kind of internalize what software, like this hidden software, looks like. So what does a deployment of some load-balanced microservice clustered thing look like? Most people would not be able to answer that question. But the more time you're exposed to it, the more it becomes burned into your inner vision. ROB: Mental model? CHARLES: Yeah. You develop a mental model. Your brain literally wraps around that. It takes time. But on the frontend, especially if you're a visual person – but I would say even if you're not – I think the same would apply to someone who's using assistive technology. It's still something that you can feel with your sense and you don't have to develop a sixth sense to perceive it. So, there's literally a problem of perception there. And so, maybe frontend work is a great on-ramp for everybody, because it's so perceptual. ROB: That's exactly why I picked it. I was trying to do iOS dev before. And I could not do it for those reasons. I didn't have that nice tight feedback loop of even though it was UI, in Objective-C you had to construct your UI and buttons out of Objective-C. Unless you wanted to use Apple's Interface Builder and that was, meh. Everybody built it procedurally. And what I loved about HTML and CSS, was I could instantly throw something on the page, attach some CSS to it, and see it change immediately. And that felt so good. [Chuckles] CHARLES: Yeah, yeah, no. And it's important to get those really tight feedback loops, especially when you're starting out. ROB: So, if we had to tie this back together, did we decide that there is a distinction between frontend, backend, and full stack? And if there is, or isn't, why? SAM: I think there's like… CHARLES: I don't know if we've… go ahead. SAM: Kind of a distinction. But it's also really fuzzy, I would say. So, if I'm going to explain what the difference is between frontend and backend to someone who maybe isn't a developer, I would always go back to a video game. So, when you see your guy… ROB: Ooh, this is interesting. SAM: Yeah. [Chuckles] When you see your guy running around and you're like, “Oh, this game looks really good. I'm really into these graphics,” but do you ever think about what it takes to save the game or what is actually being saved when you go to save it? So, if you're more interested in making the guy run and making the guy and the environment look good, you might gravitate more towards frontend. But if you're really interested in saving the data, like well what is being saved when I hit ‘save to this slot' or whatever? Then you might gravitate more towards backend. ROB: Or like the network layer of the online multiplayer? SAM: Yeah, yeah. ROB: [Laughs] That's interesting. I've never used video games as an analogy. I always go like, you know, if you're a frontend developer, you know that button that you click? That's the button I create. And then the action that happens is usually what the backend developer does. I think I like the game analogy better. [Laughs] SAM: I think the game analogy is something that most people can grasp. And most people can grasp. Like I'll tell people the difference between frontend and backend if I'm talking about Facebook. Like what I do for a job is I'll show you everything that's on your Facebook page. And when somebody, or the backend is somebody who makes all of that come into play, kind of, you know? But I think video games are easier to conceptualize that abstraction of data being saved rather than trying to explain the intricacies of Facebook to somebody. ROB: [Chuckles] CHARLES: Yeah. No, I like that. I like that. So, I guess if we achieved consensus, would we say that these do exist as broad functional categories? And a full stack developer is someone who will move in between those functional categories through the course of their career. And that generally, the trend is that the longer the career goes, the more you will do that. ROB: Yeah. I can get on board with that. I'm going to use your career as like the guiding post of that. The way you just explained it, it kind of made something click for me. You describe yourself as a frontend developer. And I think in our industry with software development and the way teams work, I think you end up specializing no matter if you call yourself a full stack developer or not. Because I do think you're a full stack developer. But you've mainly been working on frontend for the past what, three years, four years? So, I think it's okay to call yourself a frontend developer. But you are a full stack developer. But as you specialize around and amass that knowledge, that's where you become that full stack developer, right? And so, at one point in your career, you were a backend developer. And then now at this point in your career, you're a frontend developer. But now you have those experiences and you can draw on both of them and apply them across the fields, right? That's super interesting to me. So, maybe it is that you have to specialize in order to achieve the full stack. And you're never truly a full stack developer in your role. But it's possible, depending on the team and the team dynamics. It's just interesting that you can be a full stack developer, also at the same time be specializing as a frontend developer at that current time, right? Yeah, that's interesting. CHARLES: Alright, so it sounds like consensus achieved. Let's all virtually hug. [Chuckles] ROB: Send the hug emoji. CHARLES: Alright everybody. That is our show for today. We are The Frontside and we build software that you can stake your future on. We would love to hear from you, especially if you have an idea for a future podcast topic. Any news that you think is something that we should discuss, even if it's not the theme of the whole episode. And we will see you next time. As always, you can give us a shout on Twitter at @TheFrontside or just drop us an email at contact@frontside.io. If you enjoyed today's podcast, it was produced by Mandy Moore, the inimitable @TheRubyRep. So thank you, Mandy. And see you all next time.
Panel: Gui Rambo Andrew Madsen Eric Sadun Special Guest: Chris Adamson In today's episode, the iPheaks panelist speak with Chris Adamson, a freelance iOS and Mac developer from Grand Rapids Michigan. Also, Chris is an author and co-author of a number of books, including Xcode Treasures. Chris is on the show to talk about this book abut Xcode called Xcode Treasures. This is a great episode to learn about another avenue of valid information on the inner workings of Xcode. In particular, we dive pretty deep on: Book Xcode Treasures Negativity about Xcode Tools Documentation Code Warrior Hardware 32 bit issues What are the biggest frustrations with Xcode as a developer? What are the things you love about Xcode? Xcode project format Xcode not savvy with version control Apple addressing these issues Interface Builder What did you learn about Xcode when writing the book? Code Signing Sand boxing app Git control VeraCode Fonts Who needs to buy you book? Mid Level and up iOS developers need this book. Pragmatic Programmers Beta Program When are with going to see the book? Xcode for iPad? Xcode as an IDE Core Audio talk and updates And much much more! Links: http://subfurther.com/blog https://www.linkedin.com/in/invalidname// https://www.oreilly.com/pub/au/1045 Xcode Treasures https://developer.apple.com/xcode/ Picks: Gui OS Log API Andrew Online Swift Playground Juiced.gs Erica Snippity Chris We are X
Panel: Gui Rambo Andrew Madsen Eric Sadun Special Guest: Chris Adamson In today's episode, the iPheaks panelist speak with Chris Adamson, a freelance iOS and Mac developer from Grand Rapids Michigan. Also, Chris is an author and co-author of a number of books, including Xcode Treasures. Chris is on the show to talk about this book abut Xcode called Xcode Treasures. This is a great episode to learn about another avenue of valid information on the inner workings of Xcode. In particular, we dive pretty deep on: Book Xcode Treasures Negativity about Xcode Tools Documentation Code Warrior Hardware 32 bit issues What are the biggest frustrations with Xcode as a developer? What are the things you love about Xcode? Xcode project format Xcode not savvy with version control Apple addressing these issues Interface Builder What did you learn about Xcode when writing the book? Code Signing Sand boxing app Git control VeraCode Fonts Who needs to buy you book? Mid Level and up iOS developers need this book. Pragmatic Programmers Beta Program When are with going to see the book? Xcode for iPad? Xcode as an IDE Core Audio talk and updates And much much more! Links: http://subfurther.com/blog https://www.linkedin.com/in/invalidname// https://www.oreilly.com/pub/au/1045 Xcode Treasures https://developer.apple.com/xcode/ Picks: Gui OS Log API Andrew Online Swift Playground Juiced.gs Erica Snippity Chris We are X
John and Gui dive deep into the possibilities of a WebKit & macOS system-wide dark theme and discuss all the new rumors about a declarative cross-platform UI framework for Apple's platforms. Stacktrace by 9to5Mac is available on iTunes and Apple’s Podcasts app or through our dedicated RSS feed for Overcast and other podcast players. Hosts: Gui on Twitter: @_inside John on Twitter: @johnsundell Topics: Gui's 9to5Mac post about a WebKit dark mode Asset Catalog Format Reference - Apple WWDC app for macOS The WebKit open source project Episode 271 of ATP Apple's Resolution Independent UI Design patent AppearanceMaker John Gruber's post about Apple's cross-platform UI project Mark Gurman's tweet about Swift and Interface Builder HubFramework "You’re Practically a Mac Developer" LearnAppKit.io
A lo largo del podcast hemos tratado sobre los lenguajes de programación, los distintos tipos, las formas de utilizarlos, tipos de software e incluso sistemas operativos. No obstante algo en lo que no hemos profundizado tanto es en las herramientas complementarias existentes. En este caso comenzaremos con los muy conocidos y polémicos Interface Builder. Pero no solo hablaremos sobre ellos sino que también analizaremos su utilidad, pros y contras. He en esto un dilema ya que dependiendo del entorno de desarrollo del que estemos hablando existen otros conceptos como Storyboars, Nibs, entre otros conceptos que abordaremos a lo largo del programa. Una pequeña advertencia es que habrán algunas referencias a Java FX y el desarrollo de aplicaciones en iOS. Algunos conceptos están basados en esos entornos por lo que pueden haber pequeñas diferencias. Finalmente antes de comenzar te recordamos que puedes aportar ya sea economicamente con el proyecto o compartiendo el material, por no mencionar que si existe algún tema que sea de tu interés no dudes sugerirlo. Ahora si damos comienzo a este nuevo episodio. ********************************** App de iOS: https://itunes.apple.com/us/app/code-time/id1435749618 ********************************** Para Contribuir PAYPAL : davidgiordana@hotmail.com.ar PATREON: https://www.patreon.com/codetime ********************************** Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 ********************************** Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA ********************************** Medios de Contacto CANAL DE TELEGRAM: https://telegram.me/Code_Time PODCAST: https://goo.gl/QUximq ITUNES: https://goo.gl/XmDjX2 ********************************** Canciones Utilizadas OP: A Himitsu - Adventures: youtu.be/8BXNwnxaVQE ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com/ Music provided by Audio Library https://youtu.be/idlqqMHd0W4
A lo largo del podcast hemos tratado sobre los lenguajes de programación, los distintos tipos, las formas de utilizarlos, tipos de software e incluso sistemas operativos. No obstante algo en lo que no hemos profundizado tanto es en las herramientas complementarias existentes. En este caso comenzaremos con los muy conocidos y polémicos Interface Builder. Pero no solo hablaremos sobre ellos sino que también analizaremos su utilidad, pros y contras. He en esto un dilema ya que dependiendo del entorno de desarrollo del que estemos hablando existen otros conceptos como Storyboars, Nibs, entre otros conceptos que abordaremos a lo largo del programa. Una pequeña advertencia es que habrán algunas referencias a Java FX y el desarrollo de aplicaciones en iOS. Algunos conceptos están basados en esos entornos por lo que pueden haber pequeñas diferencias. Finalmente antes de comenzar te recordamos que puedes aportar ya sea economicamente con el proyecto o compartiendo el material, por no mencionar que si existe algún tema que sea de tu interés no dudes sugerirlo. Ahora si damos comienzo a este nuevo episodio. ********************************** App de iOS: https://itunes.apple.com/us/app/code-time/id1435749618 ********************************** Para Contribuir PAYPAL : davidgiordana@hotmail.com.ar PATREON: https://www.patreon.com/codetime ********************************** Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 ********************************** Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA ********************************** Medios de Contacto CANAL DE TELEGRAM: https://telegram.me/Code_Time PODCAST: https://goo.gl/QUximq ITUNES: https://goo.gl/XmDjX2 ********************************** Canciones Utilizadas OP: A Himitsu - Adventures: youtu.be/8BXNwnxaVQE ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com/ Music provided by Audio Library https://youtu.be/idlqqMHd0W4
A lo largo del podcast hemos tratado sobre los lenguajes de programación, los distintos tipos, las formas de utilizarlos, tipos de software e incluso sistemas operativos. No obstante algo en lo que no hemos profundizado tanto es en las herramientas complementarias existentes. En este caso comenzaremos con los muy conocidos y polémicos Interface Builder. Pero no solo hablaremos sobre ellos sino que también analizaremos su utilidad, pros y contras. He en esto un dilema ya que dependiendo del entorno de desarrollo del que estemos hablando existen otros conceptos como Storyboars, Nibs, entre otros conceptos que abordaremos a lo largo del programa. Una pequeña advertencia es que habrán algunas referencias a Java FX y el desarrollo de aplicaciones en iOS. Algunos conceptos están basados en esos entornos por lo que pueden haber pequeñas diferencias. Finalmente antes de comenzar te recordamos que puedes aportar ya sea economicamente con el proyecto o compartiendo el material, por no mencionar que si existe algún tema que sea de tu interés no dudes sugerirlo. Ahora si damos comienzo a este nuevo episodio. ********************************** App de iOS: https://itunes.apple.com/us/app/code-time/id1435749618 ********************************** Para Contribuir PAYPAL : davidgiordana@hotmail.com.ar PATREON: https://www.patreon.com/codetime ********************************** Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 ********************************** Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA ********************************** Medios de Contacto CANAL DE TELEGRAM: https://telegram.me/Code_Time PODCAST: https://goo.gl/QUximq ITUNES: https://goo.gl/XmDjX2 ********************************** Canciones Utilizadas OP: A Himitsu - Adventures: youtu.be/8BXNwnxaVQE ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com/ Music provided by Audio Library https://youtu.be/idlqqMHd0W4
A lo largo del podcast hemos tratado sobre los lenguajes de programación, los distintos tipos, las formas de utilizarlos, tipos de software e incluso sistemas operativos. No obstante algo en lo que no hemos profundizado tanto es en las herramientas complementarias existentes. En este caso comenzaremos con los muy conocidos y polémicos Interface Builder. Pero no solo hablaremos sobre ellos sino que también analizaremos su utilidad, pros y contras. He en esto un dilema ya que dependiendo del entorno de desarrollo del que estemos hablando existen otros conceptos como Storyboars, Nibs, entre otros conceptos que abordaremos a lo largo del programa. Una pequeña advertencia es que habrán algunas referencias a Java FX y el desarrollo de aplicaciones en iOS. Algunos conceptos están basados en esos entornos por lo que pueden haber pequeñas diferencias. Finalmente antes de comenzar te recordamos que puedes aportar ya sea economicamente con el proyecto o compartiendo el material, por no mencionar que si existe algún tema que sea de tu interés no dudes sugerirlo. Ahora si damos comienzo a este nuevo episodio. ********************************** App de iOS: https://itunes.apple.com/us/app/code-time/id1435749618 ********************************** Para Contribuir PAYPAL : davidgiordana@hotmail.com.ar PATREON: https://www.patreon.com/codetime ********************************** Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 ********************************** Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA ********************************** Medios de Contacto CANAL DE TELEGRAM: https://telegram.me/Code_Time PODCAST: https://goo.gl/QUximq ITUNES: https://goo.gl/XmDjX2 ********************************** Canciones Utilizadas OP: A Himitsu - Adventures: youtu.be/8BXNwnxaVQE ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com/ Music provided by Audio Library https://youtu.be/idlqqMHd0W4
A lo largo del podcast hemos tratado sobre los lenguajes de programación, los distintos tipos, las formas de utilizarlos, tipos de software e incluso sistemas operativos. No obstante algo en lo que no hemos profundizado tanto es en las herramientas complementarias existentes. En este caso comenzaremos con los muy conocidos y polémicos Interface Builder. Pero no solo hablaremos sobre ellos sino que también analizaremos su utilidad, pros y contras. He en esto un dilema ya que dependiendo del entorno de desarrollo del que estemos hablando existen otros conceptos como Storyboars, Nibs, entre otros conceptos que abordaremos a lo largo del programa. Una pequeña advertencia es que habrán algunas referencias a Java FX y el desarrollo de aplicaciones en iOS. Algunos conceptos están basados en esos entornos por lo que pueden haber pequeñas diferencias. Finalmente antes de comenzar te recordamos que puedes aportar ya sea economicamente con el proyecto o compartiendo el material, por no mencionar que si existe algún tema que sea de tu interés no dudes sugerirlo. Ahora si damos comienzo a este nuevo episodio. ********************************** App de iOS: https://itunes.apple.com/us/app/code-time/id1435749618 ********************************** Para Contribuir PAYPAL : davidgiordana@hotmail.com.ar PATREON: https://www.patreon.com/codetime ********************************** Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 ********************************** Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA ********************************** Medios de Contacto CANAL DE TELEGRAM: https://telegram.me/Code_Time PODCAST: https://goo.gl/QUximq ITUNES: https://goo.gl/XmDjX2 ********************************** Canciones Utilizadas OP: A Himitsu - Adventures: youtu.be/8BXNwnxaVQE ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com/ Music provided by Audio Library https://youtu.be/idlqqMHd0W4
A lo largo del podcast hemos tratado sobre los lenguajes de programación, los distintos tipos, las formas de utilizarlos, tipos de software e incluso sistemas operativos. No obstante algo en lo que no hemos profundizado tanto es en las herramientas complementarias existentes. En este caso comenzaremos con los muy conocidos y polémicos Interface Builder. Pero no solo hablaremos sobre ellos sino que también analizaremos su utilidad, pros y contras. He en esto un dilema ya que dependiendo del entorno de desarrollo del que estemos hablando existen otros conceptos como Storyboars, Nibs, entre otros conceptos que abordaremos a lo largo del programa. Una pequeña advertencia es que habrán algunas referencias a Java FX y el desarrollo de aplicaciones en iOS. Algunos conceptos están basados en esos entornos por lo que pueden haber pequeñas diferencias. Finalmente antes de comenzar te recordamos que puedes aportar ya sea economicamente con el proyecto o compartiendo el material, por no mencionar que si existe algún tema que sea de tu interés no dudes sugerirlo. Ahora si damos comienzo a este nuevo episodio. ********************************** App de iOS: https://itunes.apple.com/us/app/code-time/id1435749618 ********************************** Para Contribuir PAYPAL : davidgiordana@hotmail.com.ar PATREON: https://www.patreon.com/codetime ********************************** Curso completo de desarrollo en Swift 4 desde cero https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1 Curso de desarrollo de aplicaciones para iOS 11 desde cero https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1 ********************************** Medios de contacto: Twitter / Telegram: @DavidGiordana Correo Electrónico: davidgiordana0@gmail.com Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA ********************************** Medios de Contacto CANAL DE TELEGRAM: https://telegram.me/Code_Time PODCAST: https://goo.gl/QUximq ITUNES: https://goo.gl/XmDjX2 ********************************** Canciones Utilizadas OP: A Himitsu - Adventures: youtu.be/8BXNwnxaVQE ED: See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com/ Music provided by Audio Library https://youtu.be/idlqqMHd0W4
Functional Swift Conference Berlin - http://www.funswiftconf.com Functional Swift auf Youtube - https://www.youtube.com/channel/UCNFUO_7gsLBk4YTmZoSTk5g JLRoutes - https://github.com/joeldev/JLRoutes SnapKit - https://github.com/SnapKit/SnapKit Cartography - https://github.com/robb/Cartography Gestalt - https://github.com/regexident/Gestalt Storyboard2Code - https://github.com/dasdom/Storyboard2CodeApp Mint - https://github.com/yonaskolb/Mint Darwin Kernel - https://github.com/apple/darwin-xnu Apple Open Source - https://opensource.apple.com/ Ben auf Twitter - https://twitter.com/benchr Dom auf Twitter - https://twitter.com/swiftpainless Vincent auf Twitter - https://twitter.com/regexident Hallo Swift auf Twitter - https://twitter.com/hallo_swift SwiftDe-Slack - http://slack.swiftde.net Hallo Swift Webseite - http://hallo-swift.de Hallo Swift auf iTunes - https://itunes.apple.com/de/podcast/hallo-swift/id1225721421?mt=2
This week we talk about Interface Builder and how we write Swift UI code. Get in touch with us in the Spec Slack or on Twitter at @runtimefm. Sponsored by buddybuild.
The raywenderlich.com Podcast: For App Developers and Gamers
In this podcast episode, Mic, Jake, and Andy discuss continuous integration in production, before moving onto live rendering of custom controls in IB. The post Continuous Integration, and Live Rendering in Interface Builder – Podcast S05 E06 appeared first on Ray Wenderlich.
Jane Abernethy — part of the iOS development team at the Commonwealth Bank in Sydney — joins the couch to fill in for the globetrotting Ben, and to talk about her work, her team and IBDesignables. Also, follow up. Lots and lots of follow up. After attempting to convince Jake to use 1Password, Jelly talks about his internet troubles, and Jake follows up on his endeavours to get VDSL installed as mentioned in last week’s episode. Jane introduces herself and talks a little about how she got started as an iOS developer, which leads into a discussion of why each of the couch got into development in the first place, and what made the iPhone such an exciting device to make apps for. Jane talks about how it feels great that her mum uses the app she works on, but it’s frustrating that she hasn’t updated from iOS 6 yet, and the whole couch joins together in a chorus of sorrow about supporting older iOS versions. Delving into follow up, Jelly attempts to finalise the pronunciation of Haneke, and communicates the differences between the Objective C and Swift versions. Jake follows up on his previous follow up regarding gender diversity in tech by mentioning a Planet Money episode that discusses the history of the topic. This prompts much awkwardness, and then discussion of said awkwardness. Finally, Jelly follows up on the topic of today extensions, and how they communicate with their parent app. Returning to the topic of supporting older iOS versions, the couch talks about what versions it’s worth supporting with releases and what the 6% of users that aren’t using iOS 7 actually means. Jake mentions that it feels like this change to iOS 8 feels a lot harder to support alongside older version because of the sheer number of new features. Almost two-thirds of the way through the episode, Jake finally gets to ask Jane a few questions about her work, and what the differences between her current role at the Commonwealth Bank and her previous role at a digital advertising agency in Sydney are like. Jake also asks whether Jane’s team is looking at Swift at this point, and though they aren’t really, this prompts a discussion about IBDesignables with Interface Builder, which Jane has been exploring. Finally, Jake looks for a solution to a tableview that feels too cramped on the larger iPhone 6 plus, and Jelly tries to talk him out of detecting the device model with two lines of CGRect-based code. But will he listen? Tune in next time to find out!
This episode was recorded 17 May 2013 live and in person at Omni's lovely offices overlooking Lake Union in Seattle. You can download the m4a file or subscribe in iTunes. (Or subscribe to the podcast feed.) Tim Wood, CTO of The Omni Group, talks about how Omni got started and what it was like being a NeXT developer before the acquisition. This episode is sponsored by Squarespace. Easily create beautiful websites via drag-and-drop. Get help any time from their 24/7 technical support. Create responsive websites — ready for phones and tablets — without any extra effort: Squarespace's designers have already handled it for you. Get 10% off by going to http://squarespace.com/therecord. And, if you want to get under the hood, check out their APIs at developers.squarespace.com. This episode is also sponsored by Microsoft Azure Mobile Services. Mobile Services is a great way to provide backend services — syncing and other things — for your iPhone, iPad, and Mac apps. If you've been to the website already, you've seen the tutorials where you input code into a browser window. And that's an easy way to get started. But don't be fooled: Mobile Services is deep. You can write in your favorite text editor and deploy via Git. Regular-old Git, not Git#++. Git. Things we mention, in order of appearance (more or less): Atari 800 BASIC Tacoma, WA Commodore Apple II 6502 Assembler Atari ST Compute! Magazine Burroughs Mainframes Radio Shack NeXT Mac University of Washington H19 Terminal Fortran Mathematica LaTeX Java Ada Boeing Department of Defense VMS IBM 360 Objective-C AppKit Interface Builder Project Builder Makefiles Read-write Optical drives Wil Shipley Ken Case Greg Titus Tom Bunch Massively multiplayer games Minecraft MOOs MUSHes CompuServe Ultima Online William Morris Agency McCaw Cellular 1992 Framemaker Adobe Lighthouse Design Diagram! OmniGraffle 1994 www.app OmniWeb Blink tag Rocky & Bullwinkle Rhapsody Hewlett Packard Sun OpenStep Solaris Windows NT Be Jean-Louis Gasée Enterprise Objects Framework Core Data Avie Tevanian Jon Rubinstein Bertrand Serlet Craig Federighi Appletalk Yellow Box HP-UX Andrew Stone Doom Id Software Wil's mail OpenGL John Carmack DirectX OmniOutliner Comic Life NCSA GCD Blocks Functional programming Mac Pro Go Rust Race conditions OmniPresence Own the Wheel iCloud Core Data Syncing Rich Siegel Yojimbo Sync Services
Panel Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:18 - Interface Builder 01:55 - Custom-designed interfaces 02:32 - Tips and Tricks 03:04 - Interface Builder Buttons and Functions File’s Owner First Responder The Responder Chain Events/Actions Objects Elements Views Outlet Storyboards Segues/Segways 09:39 - Cons of Using Interface Builder Team Environments 13:13 - Custom Work Writing a custom UI 14:52 - Controllers GLKit Table View 19:09 - Static Cells and Storyboards 21:23 - Dynamic Prototypes and Prototype Cells 23:23 - Getting a Table View Cell into the Table View 24:48 - Rod’s Apps Numerology Numerology Baby Namer 25:29 - Rejection from the App Store 27:50 - Gestures 30:19 - Calendar View Picks NSBrief: Episode #97: Jon Reid (Rod) Ember.js (Rod) Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement by Jim R. Wilson (Chuck) Eventbrite (Chuck) Next Week Audio and Video in Apps Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming 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.
Panel Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:18 - Interface Builder 01:55 - Custom-designed interfaces 02:32 - Tips and Tricks 03:04 - Interface Builder Buttons and Functions File's Owner First Responder The Responder Chain Events/Actions Objects Elements Views Outlet Storyboards Segues/Segways 09:39 - Cons of Using Interface Builder Team Environments 13:13 - Custom Work Writing a custom UI 14:52 - Controllers GLKit Table View 19:09 - Static Cells and Storyboards 21:23 - Dynamic Prototypes and Prototype Cells 23:23 - Getting a Table View Cell into the Table View 24:48 - Rod's Apps Numerology Numerology Baby Namer 25:29 - Rejection from the App Store 27:50 - Gestures 30:19 - Calendar View Picks NSBrief: Episode #97: Jon Reid (Rod) Ember.js (Rod) Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement by Jim R. Wilson (Chuck) Eventbrite (Chuck) Next Week Audio and Video in Apps Transcript [This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming 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.
The role of the Mac Pro today. How Apple might manage the launch of a bigger iPhone. App design and auto-layout if the iPhone moves to multiple sizes and resolutions. Visual Studio's learning curve vs. Xcode and Interface Builder. The future of Objective C and the challenge of migrating a platform's API to a new language.
Harvard College's Computer Science 164: Mobile Software Engineering
MP4 format
Harvard College's Computer Science 164: Mobile Software Engineering
MP3 format
Harvard College's Computer Science 164: Mobile Software Engineering
PDF format
Harvard College's Computer Science 164: Mobile Software Engineering
PDF format
Software engineering, programming language, operating system, iOS, OS, iPhone, iPad, objective c, cocoa touch, SDK, object oriented design, Apple, Macintosh, tools, language, runtime, Xcode, Interface Builder, App Store, framework, UI testing, unit testin
Software engineering, programming language, operating system, iOS, OS, iPhone, iPad, objective c, cocoa touch, SDK, object oriented design, Apple, Macintosh, tools, language, runtime, Xcode, Interface Builder, App Store, framework, NSTimer, View Animation
Ce deuxième cours revient dans un premier temps sur Objective C. Après une présentation de la gestion des classes dans ce langage, il s'attache à présenter les mécanismes de gestion de la mémoire qui s'appuie sur des mécanismes classiques en programmation embarquée. Dans un second temps, la notion de vue, cruciale pour la construction d'interfaces graphiques sans utiliser Interface Builder est évoquée. Le cours se termine par une présentation de UIKit (contenant des mécanismes pour gérer boutons, sliders, segmented-control, etc.) ainsi qu'une rapide présentation de la gestion du scrolling/zooming.
Dan and Marco discuss Interface Builder vs. coding views manually, CORS and extreme iframe geekery, the impact of Apple or strong competition entering your market, the oversupply of App Stores, and whether competing tablets are too late to have a chance in the market.
Lezione 1 Panoramica sugli aspetti tecnologici dei dispositivi iPhone, iPod Touch e iPad iOS technology layers: Core OS, Core Services, Media, Cocoa Touch Concetti fondamentali di programmazione object-oriented: classi, ereditarietà e composizione. Introduzione a iOS e iOS SDK (iOS SDK contiene tutti gli strumenti necessari per il design, lo sviluppo, il debugging, e l’ottimizzazione del software per iOS) Strumenti di sviluppo per la piattaforma iOS: Xcode, Interface Builder, Simulator, Instruments
Lezione 1 Panoramica sugli aspetti tecnologici dei dispositivi iPhone, iPod Touch e iPad iOS technology layers: Core OS, Core Services, Media, Cocoa Touch Concetti fondamentali di programmazione object-oriented: classi, ereditarietà e composizione. Introduzione a iOS e iOS SDK (iOS SDK contiene tutti gli strumenti necessari per il design, lo sviluppo, il debugging, e l’ottimizzazione del software per iOS) Strumenti di sviluppo per la piattaforma iOS: Xcode, Interface Builder, Simulator, Instruments
Lezione 1 Panoramica sugli aspetti tecnologici dei dispositivi iPhone, iPod Touch e iPad iOS technology layers: Core OS, Core Services, Media, Cocoa Touch Concetti fondamentali di programmazione object-oriented: classi, ereditarietà e composizione. Introduzione a iOS e iOS SDK (iOS SDK contiene tutti gli strumenti necessari per il design, lo sviluppo, il debugging, e l’ottimizzazione del software per iOS) Strumenti di sviluppo per la piattaforma iOS: Xcode, Interface Builder, Simulator, Instruments
Lezione 1 Panoramica sugli aspetti tecnologici dei dispositivi iPhone, iPod Touch e iPad iOS technology layers: Core OS, Core Services, Media, Cocoa Touch Concetti fondamentali di programmazione object-oriented: classi, ereditarietà e composizione. Introduzione a iOS e iOS SDK (iOS SDK contiene tutti gli strumenti necessari per il design, lo sviluppo, il debugging, e l’ottimizzazione del software per iOS) Strumenti di sviluppo per la piattaforma iOS: Xcode, Interface Builder, Simulator, Instruments
Alan Cannistraro covers the application lifecycle, MVC design, Interface Builder and Nib files, control and target-action; and demonstrates HelloPoly. (January 14, 2010)
Alan Cannistraro covers the application lifecycle, MVC design, Interface Builder and Nib files, control and target-action; and demonstrates HelloPoly. (January 14, 2010)
The 3. 1 version of the iPhone SDK is available now, bringing a couple new fixes like having the OS simulator "more closely matching the device. " There are also new Interface Builder, XCode and Dashcode changes. [ iPhone Developer ].
The new system in TextMate for presenting dialogs allows you to create a custom interface in Interface Builder and then ask TextMate to present it as was it native. This is without writing any code at all. This is part one of a series of screencasts about tm_dialog
© 2020-2025 Ivy Podcast Discovery LLC
