cdevroe / tags / world

Tagged with “world” (7)

  1. The Field Study Handbook with Jan Chipchase

    Show Notes & Links

    The Field Study Handbook Kickstarter

    Studio D Radiodurans

    SDR Traveller

    Art Space Tokyo

    Kickstartup: Successful fundraising with Kickstarter and remaking Art Space Tokyo

    Transcript

    Craig Mod: “What an astonishing thing a book is. It’s a flat object made from a tree with flexible parts on which are imprinted lots of funny, dark squiggles. But one glance at it and you’re inside the mind of another person, maybe somebody dead for thousands of years. Across the millennia, an author is speaking clearly and silently inside your head directly to you. Writing is perhaps the greatest of human inventions, binding together people who never knew each other, citizens of distant epochs. Books break the shackles of time. A book is proof that humans are capable of working magic.”

    This is Carl Sagan talking about what makes books great. This is back in 1980 and what’s so weirdly compelling about this quote is that the magic of a book, despite it being relatively simple as a piece of technology, I mean incredibly simple as a piece of technology, has been in no way diminished by the onslaught of smartphones and ubiquitous internet.

    And when we say ubiquitous internet we really mean ubiquitous internet. Go to the fields of Myanmar and you will find farmers atop buffalo playing Clash of Clans on newly minted 3G networks. Walk into any café, any restaurant and you will see a sea of people looking down at their phones. In fact, our state of always-on communication of jumping from source to source only strengthens the power that is a great book.

    But what is a great book in its most simple definition? To me, a great book is a piece of thinking in which usually one other person — who’s hopefully an expert in their field or an expert of their own unique experience; and that’s an important and kind of strange caveat because sometimes people have had experiences but they haven’t put in the time to become experts of their own experience — and so you have this expert who has worked through a thought or a collection of thoughts over and over again. These thoughts can be textual or visual or some combination therein. A refinement of a kind of thinking about a specific topic. That thinking or experience is distilled and then given to others as a gift and I hope in a best case scenario as a starting point for a deeper kind of dialogue.

    I’ve been working on and with books for over 15 years as a designer, a publisher, a producer and an author and what I’ve realized over time is that the margins of a great book run deep. The more I’ve worked on my own books, the more I’ve come to realize that the white space and untold stories behind how and why a book is made are not only compelling but essential and it’s within those margins that I want to spend some time.

    The first guest on this podcast is author Jan Chipchase whose life is nothing if not oodles of white space, oodles of untold stories and unseen preparation in anticipation of sharing his insights with the world. And so today, we’re talking about his most recent book, “The Field Study Handbook.”

    My name is Craig Mod. I’m here today with Jan Chipchase and it’s a very special day for Jan. He has in his hands something that he has been working on for a long, long time. Three …

    Jan Chipchase: Yeah.

    Craig Mod: Three things.

    Jan Chipchase: Three years.

    Craig Mod: Three years.

    Jan Chipchase: Intensively.

    Craig Mod: Super intensively. So Jan, what is this that you have in your hand and why are we talking this morning?

    Jan Chipchase: I have been working on a book called “The Field Study Handbook”, which is a guide to running international field research. Basically it’s a guide to traveling around the world, decoding culture, building teams and helping clients figure out how the world out there affects how they think and what they should do next.

    Craig Mod: You gave me a sneak peek at this and I’m really excited about it.

    Jan Chipchase: You’re in it.

    Craig Mod: What? Oh man. I’m going to need some royalties on this thing now. I’m really excited about this book because your life, your work-life balance for the last 15 years has been this endless source of fascination for so many of us in the world who are designers or travelers or ethnographers. And this book is a consolidation of all of that work and thinking of your life.

    Jan Chipchase: About field work, yeah.

    Craig Mod: And how long is it?

    Jan Chipchase: 524 pages.

    Craig Mod: Yeah, I mean you just held it up for me. It looks like a Bible. It is definitely … It’s a weapon. You could use that to attack people.

    Jan Chipchase: It’s a handbook but it’s 1. … I just measured it for the first time, it’s 1.75 inches.

    Craig Mod: Yeah. It’s a mitt book. It’s not really just for a hand, it’s like for a giant’s mitts.

    Jan Chipchase: For large handed people. But having said that, it does have 80 diagrams in it. It’s not like all text. There’s 80 diagrams, there’s 50 illustrations in there, also tables, case studies. It’s well spaced out.

    Craig Mod: Yeah, I mean what I love about it is you couch as this guide to doing field work, but really, I mean, looking at the table of contents and reading the bits that you let me read and just having known you for years and talk to you about your work, this book is, it’s a guide to living globally in a respectful way. I think the respect component is so big in this book. I love it. I mean, you sent me these little samples and so much of the sample was about respect.

    Jan Chipchase: There’s a thing in our field which is human centered design, right? Putting people at the center of the process in some shape or form. A lot of people talk about that as if if you practice that, that the thing that you do will turn out good. As in good in the sense of be social and be good for society. But actually, the reality is you can use those tools for good and bad. You can make more money out of people without them realizing it. You can create solutions that shift balance of power in the favor of the few instead of the many. There’s many different ways it can be applied. Actually, the ethics of how we do this and the intent behind how we do this is one of the most important parts of this process. I’m sharing what I believe creates and draws in these rich and valid and sustainable ways of collecting data in the world out there, and using it to make a difference. Yeah, thank you for picking up on that.

    Craig Mod: Yeah. I mean, it almost, and some parts of it read almost like a travel guide from the 1800s or something. I mean, it really is this … We have this sense of the world in a globalism ironing out everything and everywhere you go it’s a McDonald’s and a McDonald’s is a McDonald’s is a McDonald’s. But the reality is that they aren’t all the same like that.

    I mean, there’s a paragraph I want to just read for a second where you’re talking about forms of incentive and you say, “For example, for home based sessions in China it’s common to arrive with a gift such as watermelon and leave after handing over an envelope of cash. In Japan small, fancy biscuits are an appropriate gift on arrival. In communities without refrigeration … ” Which is, I love that because it’s like, yeah, you’re going to be in places without refrigerators sometimes. “It is better to turn up with a live animal that can be eaten in one sitting, such as a chicken. In countries where prepaid phones are common, air time is an appropriate gift that can also be converted into cash.” In one paragraph and you have about a billion of these paragraphs like that. It’s this quick jump deep into places and ways of thinking about places that I think most people don’t get to. Kudos. I like it.

    Jan Chipchase: Thank you. I’ve been practicing this for 17 years, now, from my first job and it’s a privilege every day to be doing this kind of work.

    Craig Mod: Walk us through the elevator pitch of Jan’s last 17 years.

    Jan Chipchase: Okay, and the preamble to that is a degree in development economics in the UK. Joined a research institute at the University of Bristol. Then, moved to Japan where we didn’t meet, surprisingly because we were both out there. I was in Japan for 10 years and I worked initially as a very bad usability engineer and then morphed into concept designer. This was at Nokia’s research center in Tokyo. Then, eventually made my way up to being principal scientist in the research center. Then, in 2000 I left and I became a executive creative director of global insights, long job title. Overseeing the research practice at Frog Design, globally.

    Craig Mod: You left Nokia 2000.

    Jan Chipchase: 2010. I was at Nokia 2000 to 2009, actually.

    Craig Mod: Then, 2009 you joined Frog.

    Jan Chipchase: 2010 I joined Frog, I think.

    Craig Mod: 2010. I mean, you were there in the Nokia heyday, like when Nokia was a real company, it wasn’t gutted.

    Jan Chipchase: Yeah.

    Craig Mod: You said, if you said a Nokia, I mean that was essentially what is synonymous, it was like Kleenex for tissues. Nokia is a phone.

    Jan Chipchase: Pretty much, yeah. At that time I was there I joined just at the peak of their insane valuation. If you look at any market capsize valuation you’ll see a chart that looks Everest-esque, and I joined just at the peak of the Everest-esqueness of it.

    Craig Mod: Hopefully you got paid only in options.

    Jan Chipchase: I got paid in love and elk biscuits of something.

    Craig Mod: Yummy.

    Jan Chipchase: Then I worked on emerging markets. Products that essentially, at that time, were being sold for about $70 dollars and they went down to about $35 dollars. These days those products you can probably get new for about $15 dollars on the market. When the mobile phone went from being niche and very expensive, to becoming a mass consumer product. I was there during the heyday of that, and was fortunate enough to have done work that influenced the direction of that. Part of those stories are in the book as well.

    Craig Mod: I mean, and a lot of this was in, it wasn’t in America, it was in deep China, it was in deep India.

    Jan Chipchase: Absolutely. Yeah.

    Craig Mod: Right?

    Jan Chipchase: Yeah. I was based out of Tokyo, but I spent pretty much for the last 17 years I’ve spent half the year, up to half the year traveling the world and specializing in what was then called emerging markets. I think many of those markets have emerged and are starting to gobble up more developed markets. Places like India and China, Brazil, Afghanistan, Egypt, Bolivia. You name it, I’ve probably run a field study there.

    Craig Mod: You’ve basically spent 17 years being a professional traveler because a lot of these projects aren’t very long. Maybe you have a week, maybe you have two weeks, maybe you have a month if you’re lucky. You have to go super deep into a culture that maybe you haven’t been to before.

    Jan Chipchase: Yup.

    Craig Mod: That could be vastly different from anything that you’ve experienced before, and you have to go deep in a way that’s respectful, and make sure everyone that’s involved in the project doesn’t feel like they’re being taken advantage of. But, you also get the information that you want to get from the folks who are participating. Then you made the transition of going completely independent a few years ago.

    Jan Chipchase: Then three and a half years ago I started my own studio, Studio D Radiodurans. I’m continuing that work, but I do it for clients that I love.

    Craig Mod: And who are these clients that you love?

    Jan Chipchase: Commercial, nonprofit and governmental. There’s a couple on the website, but to be honest we, frankly, it’s actually much easier to conduct the work when people don’t know who the client is. I like to keep those relationships a little bit discrete. There’s a couple that the clients wanted to push out and they’re on the website, StudioDRadiodurans.com.

    Craig Mod: Just for those listening, it’s funny I asked that because I just wanted to tease Jan because Jan doesn’t even tell me in private who he’s working for. It’s always some … I mean, he’s the ultimate client tease. He’ll be like, “We just finished this amazing thing that I can’t tell you anything about.” I’m like, “Come on? We’re at a whisky bar. Just tell me.” “No, can’t do it. You’ll know. You’ll know someday, Craig.” That’s the response I get.

    Jan Chipchase: There’s two ways to know about the project. One way is to be the client and the second one is to be hired onto the project. Come work with us again and you’ll be working on some fantastic things. That’s part of the fun, right? Is to work with people you respect.

    Craig Mod: Mmm (affirmative).

    Jan Chipchase: I certainly would like to invite you back.

    Craig Mod: Yeah, thank you. You’ve basically, you’ve spent 17 years going deep into all these places and what was the, you’ve had one other book come out. What was that book?

    Jan Chipchase: That’s called Hidden in Plain Sight and that was published by Harper Business. That went through the formal book publishing process. I mean, that was be approached by an agent and then assigned with an agent and then a year spent on writing a proposal. Funny, a writer to work with as well because I didn’t have enough time and I’m not even convinced at that time I had the skills to work consistently. Then, another year writing the book and then it, you hand it over, right? And nine months later it appears on the shelves and it’s this slightly … It’s lovely to see it out there. It did okay in the US. Nothing special. Did pretty well in Japan, Taiwan and actually, strangely, became a best seller in South Korea.

    Craig Mod: The trick is you only need to sell seven copies in South Korea to be a best seller.

    Jan Chipchase: Three.

    Craig Mod: Three, okay. That’s a little known cultural fact. No one in South Korea reads books. If you sell three, you’re on the top of the list.

    Jan Chipchase: Yeah.

    Craig Mod: What was that book about?

    Jan Chipchase: That book was about decoding culture, but that was really about how to see the world differently by asking questions that are maybe a little unusual, that you’re not used to answering. The kind of questions that you gave up answering when you turned 10 because you’d figured stuff out. You don’t, no longer saw the eye, the world through fresh eyes. For example, why don’t people write in the shower? Why do people go to the bathroom when they do, and not before or not after? What compels us to have a particular kind of behavior? These are really obvious questions, but when you delve into them, and you unpack them and you look at all the things around them and then you put them into a cultural context, you end up with this … You end up revealing things that you never really knew when you started out.

    A lot of our clients they have, I mean, literally they’re all washing data, right? They have tons of marketing data. Increasing they have data analytics, they’re live or near time data based on actually usage. That tells them a lot about what people are doing and it tells them a huge amount about how they’re doing it. But really they’re missing the, for me, the most important component, which is why people are behaving why they do. For that you need to understand context. What I do when I run these projects is I help organizations understand why. And fundamentally if you understand why, it can take you in a very, very different direction than if you only understood what or how. That’s the crux of it.

    Craig Mod: If this first book is about figuring out how to get back to beginner’s mind, approaching things with a set of seemingly obvious questions, but that help you get to the why of why people are doing stuff. Is “The Field Study Handbook” the how to go ask those whys, to get to those whys?

    Jan Chipchase: It’s two things, yeah. One part of it is the how to. Literally it will take you from the initial pitch of this is why I think we should invest in this kind of research to helping form what we’re doing in our organization or to a client. Through to running that project. Through to figuring out how to build an international team, that you have a trusted relationship with, that gives you a better opportunity of getting to the real crux of the matter or the, closer to the truth. All the way through to delivering it and sharing it. That process of sharing in such a way that you actually influence people around you. You want to inform them and you also want to inspire them. A lot of organizations have left reigns and right reigns and you have to appeal to both sides of it. Literally, that’s the how to. There’s a lot of people particularly they put out kits. Follow these five steps, you’ll figure that stuff out. But really I think it’s missing the biggest component, which is how do you align your own intent, how do you confront your own intent for why you want to do this? Because everyone wants to travel. Nobody says no to it, right? Especially to interesting places. How do you confront that, and how do you help understand what your organization’s intent is and how do you redirect that intent to something with a greater alignment to what people actually want and need? Rather than just what the organization wants, thinks it wants and needs based on a different kind of data. The why to, for me I don’t think anyone’s written a why to for this kind of stuff.

    Craig Mod: A lot of these projects seem fraught with potential for ethically fuzzy stuff to happen. And, how do you think about that and how do you deal with that?

    Jan Chipchase: I’ve been practicing for many years, and I’m not saying there aren’t logistical challenges to run it, but probably the most interesting thing on any project is the ethical issues that you confront. Because the world is very fuzzy and a lot of the places that I work have a very variable rule of law. Sometimes the police are the most corrupt people there, or the most obviously corrupt institution. We get hustled for bribes and shaken down. We need to figure out what’s going on, but we want to do and we want to come out of it with a smile on our face for the right reasons, right? For me the ethical component really starts, always starts with the local team. When people hire us, or when people think about what we do is they think we decode culture, which we do. But actually we decode culture and local cultures and for that we need a local team, but we translate it to an organization and to a project. If you don’t understand that organization and if you can’t speak the language of that organization, then you’ve failed. We’re really a bridge between the local culture and the organization and what they’re trying to do. The first part of that is building a local team that trusts you. It’s not necessarily absolute trust. Occasionally it is absolute trust, as in life and death trust. But for most projects it’s a degree of trust.

    Craig Mod: Can you give an example of a life and death trust situation?

    Jan Chipchase: Okay. I can do, but let’s start with a slightly more trivial one, which is when you land somewhere and someone is showing you around and they’re introducing you to their social network. Their body language cues that they will make that introduction. If they do not trust you, if there’s any suspicion, that will come through unconsciously in the way that they communicate with their peers and their peers will pick up on it, or the neighborhood will pick up on it, right?

    Craig Mod: Mm-hmm (affirmative).

    Jan Chipchase: You end up with a distorted view of things. People may want to tell the truth, also, but they don’t necessarily remember accurately, so there’s all these different ways of getting to this notion of truth. The question of higher risk places. I think one of the projects in Afghanistan we had a local crew. One of the local crew was offered a large sum of money to facilitate a kidnapping of one of my colleagues. That’s what I was told by the local crew. There are so many different ways that that could play out. It may not have been true, that person may have been wanting to raise their profile. I doubt it with the relationship that we had with them. It may be that someone did make that offer, but they weren’t going to follow through on it. They may have been using it to blackmail person. If they’d accepted they may blackmail them. It may be true and they might have killed that person. The point being is in those situations where that kind of thing arises, you want to make sure that there is a local person on the ground who puts you and your team ahead of these other opportunities that may arise. You do that by building trust. How do you build trust? Fundamental the world over, it’s about showing respect from day one. Also, earning respect in negotiating appropriately. If you pay over the odds in Burundi for a guide, you’ll be considered an idiot. If you pay under the odds in Burundi for a guide you’ll be considered an exploitative local. And, there’s a million and one interactions where it’s actually very subtle about whether you can pull it off or not. And all of those things go into a process of building trust.

    Another thing that we do to build trust is we tend to hire a place, which we call a popup studio, a live-work space where we like to have our international team and our local team working side by side. I strongly believe that a team that sits around the same table and drinks water from the same jug and sits on the same toilet, or squats on the same toilet as well, has a very different level of trust than one that meets in a hotel lobby in the morning and then goes out.

    Craig Mod: Sure.

    Jan Chipchase: I mean, you’ve been in a popup studio, you’ve experienced some of that.

    Craig Mod: Mm-hmm (affirmative).

    Jan Chipchase: Right. That’s one of the steps in building trust.

    Craig Mod: Yeah, I think that’s completely true. Would you say, just to bring up an example, a really banal example of how trust gets you closer to truth more quickly. I learned when I was working with your team out in Myanmar a year and a half ago. For example, you go into someone’s home and you ask them, “How many times a day do you call your spouse?” They’ll inevitably say something. “Two or three times.” You say, “Can I just see your phone? Is that okay?” Having that trust where they’re willing to give you their phone, where you can look at their call records and then looking at the call records you realize it’s totally not what they thought the number was. It’s like getting to that truth of living, experience culture or whatever is completely contingent on having that trust. And building that trust in the case of going to someone’s home within minutes, right?

    Jan Chipchase: It may seem like it’s within minutes, but really you’ve built trust with a layer around that home with other people who have that established relationship.

    Craig Mod: Right.

    Jan Chipchase: Really, the book shows you how to build a team anywhere in the world with a sufficient level of trust. It isn’t a thing that you can just go out, read the book and go out tomorrow and it’s all going to work. It takes a lot of practice to read social situations. This isn’t a become a researcher in the next hour, book. This is a what direction do you want your life to take? If you want to decode and understand the world out there, I will give you the tools and I think a ethical framework in which to approach that. And it’ll be very, you will, I believe your life will be more rewarding for it. Mine one certainly has been, and I think through the work that I’ve conducted I think we’ve impacted quite a few people.

    Craig Mod: And even if you’re not doing work, even if you’re just traveling on your own there is something tremendously powerful about this text and all of the lessons that you have put into this. In the sense of if you’re traveling alone and you’re going to a country, there is a skillset totally, it’s totally a skillset to go deep in a way that is meaningful, that is not superficial, that is getting off the beaten paths in interesting, non … I don’t know how to say this. But, getting off the beaten paths in a way that isn’t obsessive about getting off the beaten paths. That is more of a natural flow into the culture, into a different country. One of the great gifts of this book is sharing that. Sharing those small, little insights about making yourself a better traveler, a better person, a better global citizen. What’s also cool about this book is that it’s a self published enterprise.

    Jan Chipchase: It is. Not only that, the reason why it came into being is six years ago you published Art Space Tokyo and I was so impressed with a human being going through the process of creating this beautiful, tangible object. And you did such a great write up of the backstory to that, that I thought it was possible. That was six years ago and I was just starting writing Hidden in Plain Sight. Those two years of that process I was taking notes for “The Field Study Handbook” and then after those two years I’ve spent four years, pretty much every day four years working on this book with a goal of publishing it myself.

    Craig Mod: Part of the impetus was reading the Kickstarter essay about self publishing and the accessibility of it and things like that. Then, was there anything about the last process that you didn’t like that you wanted to … Pushing it through the traditional machine, was there something that you didn’t find comfortable about that?

    Jan Chipchase: First off I’ve got to say I’m very grateful for my editor and Simon the writer and the team involved. That said, and I learned a lot from the process. I learned about whether you can take credit for success, in a way. It might sound weird, because there’s so many people involved in the process.

    Craig Mod: Sure.

    Jan Chipchase: And whether you should take responsibility for failure as well if it doesn’t do well in a market. But really once the book was finished and it was handed over, it just felt like it belonged to someone else. When the sales started I didn’t really get a sense of impetus or feedback. Since that book came out I actually published a couple of ebooks, PDFs you can download from the site. I actually have a closer relationship to the people who purchased that because I get a little ding, “This human being has invested $4.99 in spending time on something that you’ve written.” That commitment to an idea and spending time is more meaningful to me than a royalty, an advance on a book or a royalty check. With the Hidden, sorry, with “The Field Study Handbook” I wanted to be much closer to that process.

    Craig Mod: Right, and probably in having done one, I think it’s important for people to push a, pushing a book through a traditional system, I think, is you learn a lot. I also think that it’s easy to poo-poo that stuff. It’s easy today to say, “Everyone should self publish.” Or, “Everyone, forget the big five, or whatever, the big six, big four.” Whatever they’ve consolidated down to, now. It’s easy to say those things, but I think there’s, first of all there’s tremendous value in traditional publishing systems. For certain kinds of books it’s really unbeatable. And for getting to certain corners of certain markets it’s almost impossible to do on your own as an indie publisher.

    Also, if you are lucky enough to not need an advance, if you have other work that you’re able to use to, that doesn’t take up 100% of your time and gives you a little bit of time. You’ve done an incredible job, I think, of creating space in your life to work on “The Field Study Handbook” despite having every excuse in the world not to be doing it. If you have that self discipline and you don’t need the advances and things like that, then I think it can be wonderful. Now that you have, you’re on the cusp of putting this thing out into the world. In fact, you’re so on the cusp that you just came back from somewhere a couple days ago where you were looking at something connected to the book. Do you want to talk about that?

    Jan Chipchase: Sure. Yeah. I’ve just come back from Iceland. I mocked up the book and reached out to a number of printers in the US, Canada and Iceland. Iceland just felt like the right fit. It’s Oddi Printing in Reykjavik. I’ve just come back from a four day trip to Iceland. That was fun.

    Craig Mod: Nice. Actually, Oddi was the printer of the first book that I ever designed myself.

    Jan Chipchase: Oh, really?

    Craig Mod: Yeah. Kuhaku was the first book that I worked on and they were printed at Oddi because Oddi was the printer that McSweeney’s used for the most part. And back in the early 2000s, late ‘90s, if you were doing any kind of indie-ish publishing McSweeney’s was your patron saint. We stalked them and stalked their colophons and copyright pages and were like, “Where are they doing these things?” Yeah, ended up going to Oddi as well. It’s funny, it’s almost like a rite of passage to go have something printed in Iceland. They’re the only printer in Iceland, right? Aren’t they the …

    Jan Chipchase: No, there’s a couple of other much smaller printers. They were very accommodating and created this beautiful mock-up of the book itself.

    Craig Mod: Speaking of beautiful, I mean this is a gorgeous looking book. Can you explain the cover a little bit?

    Jan Chipchase: The book is illustrated by Lee John Phillips who’s a technical illustrator in Narberth, Wales. He’s incredibly talented. You should Lee John Phillips on Instagram and you’ll see what I mean. We took one of his pictures, which was a garlic bulb and we blew it up. In blowing it up it feels like a contoural map of a mountain or something like that. I wanted to have something that survived the squint test. You look at it and you’re not quite sure. Like, “Is that a landscape? Is that a … ” Then when you open the book itself you’ll see that there is the smaller, finer version of that exact detail in all its technical penmanship beauty.

    Craig Mod: I mean, that’s the thing these illustrations, it has to be said. You just want to lick the pages. I mean, they have that, it’s that Wall Street Journal dot pattern style, but with more pizazz and a little more of the human hand involved. They just look gorgeous. I mean they’re the sort of thing that a filter couldn’t do justice to with a photograph. But this man in Wales he does magic with his black and white lines. It’s pretty incredible. And you have a hit of color on the cover as well.

    Jan Chipchase: Yeah, there’s a little splash of color. Originally we were thinking of just selling through Amazon. We’ll drop ship from Oddi’s warehouse in Maine where they ship things to import them to the US, through to the Amazon warehouse and put it on sale there. Yeah, there’s a special color and I think part of the reason was that we wanted it … Or we, I’m sorry, I’m working with my creative director here in the studio Keiko Mori. We wanted it to survive the squint test on Amazon. We wanted it to work in a thumbnail. I think some of the, like if you think of Koya Bound, your own book, that’s quite a subtle book to put on a Amazon page and have distinctive in a lineup. That little splash of color is to make it a little bit more distinctive, especially across different kind of collateral.

    Craig Mod: I think it looks great.

    Jan Chipchase: Thank you.

    Craig Mod: Yeah. I mean, and what font are you using on the cover there?

    Jan Chipchase: That one we definitely, definitely ripped off Art Space Tokyo. It is Fedra, Fedra Sans Standard and Fedra Serif Standard. We also used condensed on the diagrams.

    Craig Mod: Fedra, I mean, I love Fedra. I mean, when I was doing lots of book design 10 years ago I had these moments where I’d just spend weeks going through every font I could possibly find. And Fedra was the family that I committed to. I married Fedra, basically as a book designer. Koya Bound is also Fedra.

    Jan Chipchase: Oh, is it?

    Craig Mod: Yeah. I use Fedra for everything and I’m not ashamed of it. It’s so good. It’s so beautiful. It’s a beautiful, distinctive, highly readable, but has its own character but doesn’t overwhelm the page. It’s just feels great. It’s from Typotheque over in, I think the Netherlands.

    Jan Chipchase: That’s correct, yeah.

    Craig Mod: Yeah.

    Jan Chipchase: Actually it does a great job in supporting different character sets as well. They’ve really internationalized it.

    Craig Mod: Yeah. It’s wonderful. I think you should think about doing a Kickstarter for this thing. I mean, it just feels, because you also run, you run a luggage company. It just feels like there’s such an obvious confluence between the amazing gear that you’re producing and what this book entices people to go do in the world.

    Jan Chipchase: Yeah, maybe a little context of that. When I was starting the book, around the same time I was commissioned a custom piece of luggage for the kind of travel I do. Basically I want to be able to carry stuff, sometimes a lot of expensive stuff, and actually sometimes a lot of cash because we have to pay payroll for a team of 20 people or however many people in cash sometimes.

    Craig Mod: And you might be in a place, and you’ll be in a place that has no banks or ATMs.

    Jan Chipchase: Yes, but a lot of people with sticky fingers and a lot of checkpoints and … I wanted a piece of luggage that basically people ignored and would be less likely to be pulled aside at checkpoints and check-ins. I could carry on, it sits under a seat on the plane. I designed a piece of luggage, it’s called the D3, it’s a duffle. It’s made from this ultra light, amazing ultralight material called Dyneema. It’s a particular, a blend of that. It’s about twice the strength of Kevlar, or if you want to put it another way, half the weight of Kevlar for the same tensile strength. It floats in water, it’s that light as well.

    I made a piece of luggage for that, and then a year later I made another prototype and then people like yourself saw it and said, “Hey, can I have one?” I made 10 and there were 10 beta testers of which you were one. I remember you feeding back in the report into the D3 owner’s manual, which we had online, this big Google Doc. This was before it was a company, or even decided, before I decided to even sell it. Then, three and a bit years ago I launched it as a luggage brand and we make duffels and travel accessories for field work.

    One of the things that we’re going to do for the launch of the book is introduce a couple of new items, specifically for field work. If you buy the book and you like to get out there and take notes and figure out what’s going on in the world out there, and document it, have I got something for you.

    Craig Mod: Nice. I mean, I think the D3, that piece of luggage is a great example of from the outside you look at it and you go … You have the D3 and then you have this other thing, you have this other thing called the Hauly. It’s like it holds a million dollars in used $20 dollar bills. Just enough sized. From the outside you look at it, you go, “This is for drug cartels in South America. What’s this?” But, no, you have literally been in the field in places where there aren’t lots of ATMs where you have to pay a bunch of people a bunch of cash out in the field and you have to be carrying the equivalent of a million dollars. This comes out of that need. I love that.

    Jan Chipchase: There are people who have jobs where they need to carry a lot of cash. It’s actually not used 20s, it’s used or new $100 dollar bills.

    Craig Mod: Okay, 20s would be insane.

    Jan Chipchase: It would be insane. It would be five times the weight.

    Craig Mod: Yes. Yeah, but that piece of luggage as being born directly from a real need in the field. Then, this book as being an enticement into the field and that piece of luggage as existing feels like a cool, I don’t know. I can just see the Kickstarter campaign that’s like, “Get the book and the luggage. They go together.”

    Jan Chipchase: And maybe similar to yourself is if you do interesting work, and you interact with people who are living interesting lives, it tends to generate its own momentum for new interesting things. Things to keep you engaged and pushing you at the boundary of the craft. I think with the luggage in creating these things, we ended up with attracting conversations from people who are pushing the boundaries. They are in places where they are carrying a million bucks and they want to have that additional protection.

    Craig Mod: Who do you think the audience is for this Field Study Handbook? Do you think it’s like, is it a designer in a startup in Silicon Valley? It is someone who’s working for a think tank in Washington D.C.? Is it someone who’s an independent consultant? Who’s the people that you’re trying to touch with this book?

    Jan Chipchase: “The Field Study Handbook” is for anyone that wants to understand what is going on in the world. Most of the people who currently practice that are designers, strategists, they’re in brand, communications, public policy partnerships. Because the emphasis on the handbook is about international research, it really will support anyone who is creating anything that is used beyond their boarders. They have to think beyond what they know and I give them the tools and the techniques to be able to go beyond their boarders and bring that into their organization, into their work life. That’s on one level. I think there’s another thing. I think it’s for anyone who is a traveler, who wishes to travel and who wishes to understand more about the places that they travel to. They want to have a richer, more rewarding travel experience. In that sense it’s for everyone, I think.

    Craig Mod: But this feels like a book for living in the future. It feels like the inevitable direction we’re moving in. Is one of a more globalized universe, globalized earth where more cultures are interacting with other cultures than ever before in the history of humanity. Despite recent nationalist tendencies, the future pattern is inexorably globalized living. This book feels like a blueprint for living in that future. And that if you work in any industry that touches the world, you are going to get value from it.

    Jan Chipchase: Yes. It’s a book for coexisting.

    Craig Mod: It’s a book from the future about an ideal, the utopian version of where the world could possibly [crosstalk 00:40:27].

    Jan Chipchase: You say utopian, but it’s not dystopian, but it isn’t that shiny utopian thing.

    Craig Mod: Sure.

    Jan Chipchase: That vision, it’s a very messy and beautiful and gloopy, dusty, touchy feely, snotty, version of the world. It’s the real world.

    Craig Mod: When I say utopian I mean in the sense of this is the utopian traveler. This is the idea traveler is someone who thinks about the world in this way, approaches other cultures with this respect and openness and open mind and open heart and is curious and hungry. It’s a book without malice. The world can be messy and the world will be messy, but it feels like it’s a handbook that comes from a kind place. When I say utopian I think my goal, I think it’d be ideal if everyone approached the world from this kind of place. I don’t know. It seems like a good stake in the ground.

    Jan Chipchase: Yeah. And we’ve costed, actually, to be as … It’s pretty hefty and print costs are pretty high, but we’ve costed it to be as accessible as possible.

    Craig Mod: Will it ever be released just digitally? For now it’s only in print, right?

    Jan Chipchase: It’s only in hardback and I just devoted all my energy and my family’s energy and the studio’s energy into getting it to this place. I’m just going to put it out there and see the reaction to it and then figure out what I want to do next.

    Craig Mod: I think this is the right sequence because artifacts, printed things, stuff that you can hold in your hand, things that you can hold in your hand have a certain power about setting intentions and also about being present in someone’s life. A book sitting on a table is going to call someone to try something far more frequently than a PDF lost in a folder or a Kindle book lost on a Kindle that’s sitting in a drawer or something like that. I think it’s a great place to start from the artifact. Then I’m definitely doing to push you to open this up in many different ways eventually either though websites, super accessible websites or digital downloads or digital education stuff. I’m going to push very hard for that in the future, but I think this is a great starting point.

    Jan Chipchase: My studio does offer training for organizations. I mean, we do run field research around the world, as well. You can hire us in if you want to run a larger scale project. I mean, some of the, one of the things that I enjoyed about Art Space Tokyo was when you put it out in the world, there was the backstory to it. That was such a rich component, particularly at that time where that wasn’t so widely available and wasn’t so necessarily beautifully articulated.

    With “The Field Study Handbook” there’s a number of components to it. There’s the luggage component and the field study accessories component, which comes from our own luggage brand. There’s training and workshops. I mean, that’s there too. There’s things like wallpaper downloads for Lee’s beautiful illustrations. Then there’s a second smaller book called Sustainable Data. I believe that’s the only book that could be filed under the Library of Congress under Data, Ethics, Gardening and Cookery.

    Craig Mod: A book is a start of this constellation of work and connections and interactions and discussions. It sounds like there’s a bunch of cool stuff coming out connected with this.

    Jan Chipchase: Yeah, I mean ultimately it all comes back to conversations that it starts, right?

    Craig Mod: Yeah.

    Jan Chipchase: And what those conversations lead to in terms of a life lived and journeys undertaking. People that we love and feel close to, right?

    Craig Mod: A life well lived.

    Jan Chipchase: Yeah. Who can ask for anything more?

    Craig Mod: Great. Thank you, Jan, for making the time today to chat.

    Jan Chipchase: Thank you, Craig, for having me on your podcast.

    Craig Mod: Yeah.

    Jan Chipchase: What is the podcast called, by the way?

    Craig Mod: It’s called Let’s Talk About Books.

    Jan Chipchase: Okay. Did we talk about books? Yeah, I guess we did a bit.

    Craig Mod: We’ll have links to all this stuff down below and wherever below or above wherever it lives in whatever thing you’re listening to this in. How do you end these things?

    Jan Chipchase: I think you need a jingle.

    Craig Mod: [hums jingle] We’re done.

    https://craigmod.com/onmargins/001/

    —Huffduffed by cdevroe

  2. Advanced Git with Tobias Günther | The Web Ahead

    Jen

    This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I’m your host Jen Simmons and this is episode 79, I think. Right? Yeah, 79. It’s weird, we haven’t done… we’ve only done maybe two episodes in the last four weeks so I feel a little out of practice. But meanwhile I’ve been obsessing about The Web Ahead actually because I am building, finally, building a website for the show. Hopefully it will be out soon. I’m hoping in the next month to launch it. Maybe even by the end of August 2014. But if not, then early September 2014. So I’ve been loading up content and looking at old shows and just staring at transcripts and it’s been kind of amazing, actually, to realize, 79 shows… [laughs] is a lot of shows, a lot of topics, a lot of good stuff. So I’m really excited to get the website finished and in a place where you can look at it. So I’m going to start talking about it on the show simply because I know a lot of these episodes, people listen much later than when they’re first recorded. So perhaps you’re listening to this and the website is already out. We’re still totally on 5by5, all the shows are still totally there. All the pages on 5by5 are still, all those links will still totally work, the show notes and such. But we’re also going to have it over on the new website where there will be a lot more information about guests, about the sponsors, and about eventually, I don’t know that I’ll launch with this turned on right away, but later I want to have a place where listeners can submit examples of, like, "Oh, look at this awesome WebRTC project I just did or I just found. Let’s put that on the WebRTC page." And make it much easier for you to find older shows. Maybe you really want to focus on content strategy and listen to all the shows about content strategy. There will be a page just for that, where all of those shows will live together and you can find them. ‘Cause now that we have more and more and more shows, it’s… that’s a lot of hours. [Laughs] So, maybe you want to be able to sort of focus in on a certain topic or subject or go back and listen to stuff. So that’s the idea. But I also wanted to talk about it, bring it up, because there are people who are totally helping make this project happen. And it’s happening faster because of their help. So you can go over to, this is going to be just a freaky place, but github.com/jensimmons/thewebahead/issues. I’m just using because, you know, it’s here, easy to use, an issue tracker on GitHub to list a bunch of issues that people are helping with. People are totally helping load up content, track down bios for our dozens and dozens and dozens of guests and stuff like that. ‘Cause it’s taking time and it’s making it much faster. So I also wanted to say thank you to Jenn Schlick, who’s done so much work transcribing the shows and now also helping put those transcriptions on the website as well as other things. Jason Neel and Matt Sugihara… is that… man, I’m sorry, Matt, I don’t know how to pronounce your last name. Sugihara? Phil Jones, Robert Fonó, Ross Penman, have all been really great. And Sean Fitzpatrick, who also knows Drupal, and he’s been helping with some of the Drupal. It’s all Drupal website built, Drupal backend stuff, he’s been helping with some of that, had some great suggestions on some modules I hadn’t thought of. So thanks to all of them and to everybody else who’s about to start helping out. It’s really been fun to work with a team again. Like a little fun volunteer open-source-y type of team.

    So enough about the website. Check it out once it’s up. And now I have no choice but to finish it. [Laughs] So my guest today is Tobias Günther, who is gonna explain all the hard stuff for us and make it more understandable. Hi, Tobias.

    Tobias

    Hi Jen. I’ll do my best, thanks for having me.

    Jen

    That was a long, rambling, Jen-only intro. [Both laugh] The two of us are going to talk about Git today. And you are one of the founders of Fournova, who puts out Git Tower.

    Tobias

    Exactly. Git is a… more than a hobby for us, to say that.

    Jen

    Yeah. Like, I figure you probably think about Git and how Git works and how people use Git pretty much all day, every day.

    Tobias

    Yes, yes, because we make a Git client, a Git desktop client for the Mac, so Git is our daily work and we think a lot. We indeed think a lot about how people use it, and yeah, sure, how to make it easier to use. Because it is a bit complex but also, well, a very good system. So, good to learn to it.

    Jen

    Yeah. And I’ve been using Git Tower since the very beginning. I don’t remember if it was still in beta, version 1, or if it had just come out, but it felt early.

    Tobias

    Yeah, I think you were part of the beta, really. Yeah.

    Jen

    Yeah, I think I was, ‘cause I remember shopping around and looking, there were maybe two or three or four different Git GUI clients, which basically means I’m a loser, not as good as a developer [laughs] because I’m using a piece of software where there’s lots and lots of buttons and pretty diagrams and lists and things to click on and I use that to make Git commits and pushes and merges and fix merge conflicts and all that stuff.

    Tobias

    That’s a common misconception, so you’re not a good developer because you’re using GUI applications. We’ll talk about that later on. [Both laugh]

    Jen

    Yeah, I mean, I don’t think that that’s true, but I do get that kind of, like, "Ugh, you should be using the command line if you’re a real developer." [Tobias laughs] And people ask me, "Why do you use a GUI?" And honestly, it’s because… I guess if I were a developer who’s on the command line all day, everyday, then it would be natural to only use Git on the command line, perhaps. But many times, when I’m writing code, what I’m actually doing is designing. And my brain is in this visual mode, in this sort of spatial mode and in this mode where I’m thinking about where things are in the world and moving things around and I don’t want it to be linear and language-based. I want my workflow and what I’m actually doing to be much more visual and much more about digital versions of physical spaces. And in that way, having a GUI client really fits what I’m doing, instead of yanking me out of what I’m doing.

    Tobias

    Yeah, absolutely understandable. Even the hardcore developers, the nerds, do use a GUI sometimes. So here at Fornova, well, I guess we’re nerds, we use the command line and the GUI side-by-side. So even we at Fornova still use the command line. We don’t push it away and only use the GUI client and vice versa. Still both using both side-by-side is still absolutely, well, great. Yeah.

    Jen

    So what are some of the things that you… ‘cause I know that you also teach Git and you’re putting together books and tutorials and stuff about Git. What do you think are some of the things that are maybe the, um, where people get stuck with Git? Where they… you know, they get through the basics, and they kind of, I mean, of course, the hardest thing is, "What the heck is it? Why do you need to use it?" Once people get past that and they’re using Git and they’re making commits on a daily basis and that’s how they’re working. But then they get tripped up. Like, what kinds of things do people get stuck on, do you think?

    Tobias

    I think it’s two main things. The first one is branching, actually. It’s hard to get your head around branching if you’ve never used it before. So that’s definitely a big part of the explanation. And the other thing is coming from a different version control system, and I don’t mean another distributed one like Mercurial, but a centralized one like Subversion. Maybe people are coming from Subversion these days and, well, it’s a different game. Getting your head around the basic concepts in a distributed version control system like git, that’s a big problem. Letting go of the old concepts while looking at version control with a fresh mind. That’s really a tough thing to do.

    Jen

    Yeah. So let’s talk about branching then. About why you would want to use branching and when and then maybe what about it is hard.

    Tobias

    Yeah, yeah, sure. The reason to use branching is, you want to be sure that you’re allowed to mess up, actually. You want to be allowed to make mistakes and that is the reason why you can use branches. Because if you’re using branches, your topics are separated clearly between each other. If you’re not using branches, you’re putting all the stuff in the same, let’s say, context. Let’s talk about branching like they’re folders on your computer. You want to put invoices into the invoice folder and graphics into the graphics folder. If you mix that up, chaos is the result. And that’s the same when developing stuff. Separating topics with branches is a great thing and it’s your safety net, actually. If you make mistakes in one context, that’s not a big problem because all the other contexts, all other features, a stable line of your code, is still safe and won’t be broken by that. So that’s the biggest thing, the biggest reason to use branches, actually.

    Jen

    Yeah, I mean, so you’re basically, you’re on master. Anything anybody ever does is automatically put on master unless they switch into another branch. You make a branch. And that’s one of the things, I guess, the big things when… it now feels like an epic decade ago, but I guess it was only maybe three years ago, four years ago. That people were switching from SVN to git, and it was like, hey, it’s super easy to make a branch, do it, so you just clickity-click, in my case, [both laugh] or on the command line, type whatever it is you’re supposed to type, and you make a new branch and then it’s like a parallel universe where you can experiment and do crazy things.

    Tobias

    Absolutely. Yeah. And people came from Subversion and branching wasn’t invented by git, by no means. Subversion knew the concept of branching, too. But people knew, "Wow, branching is really difficult in Subversion so… I’m not sure if I want to use that in Git either." So that’s a big problem because branching in Git is a whole different story and it’s a lot easier. You should give it a chance.

    Jen

    So, I mean, I feel like, I work alone a lot and I use branches when I want to kind of go down a weird path. Especially if I’m designing and I’m like, "Oh, I have an idea for designs, but it might be completely…" It’s the same reason I switch and make a new copy of a file in Photoshop or something. ‘Cause I know I’m about to do something really crazy and I might want to just throw the whole thing in the trash and I don’t want to have to step back through history or figure out where it was in the past… I just want to be able to chuck the whole thing when I decide that it’s a failure. And that’s a great reason to make a branch. But that’s not the most common reason that people make branches. And what I’ve seen a lot when I’ve worked on development teams is that… I guess sometimes it’s been like, "Ok, let’s each make a separate branch." So there’s, like, the "jen" branch and the "fred" branch and the "aaron" branch and the "wally" branch and then each person is in their own little space and they can do whatever they’re doing and they push their work back to master when they feel like it’s ready. But what I’ve also seen more common is that people make feature branches and that every time there’s a ticket, a user story or a bug ticket or something, somebody makes a branch to go with that particular ticket, and they do all the work for that ticket in a branch, and then they push that back into the main repo. What is it that you’ve seen when it comes to… not so much the technology, ‘cause what the branch technology does is fairly static. But the ideas, culturally, on teams, how to use branches and why to use them and what to make, when you have rules on your team about what everybody’s supposed to do. Like, what workflow is it that seems to work well for people?

    Tobias

    Yeah, yeah. So that’s, as you said, that’s different for each team. The most important thing, I guess, is to agree on a common workflow on a team. Actually there are two big workflows that can coexist, even, in a project. One is a topic branches, like you said. For every topic, and by topic I mean a new feature, a bug fix or an experiment or something, there’s a new branch for that. That’s topic feature, by definition is, well, is short-lived. It’s not there until the end of the project but only until the end of that feature or until the bug is fixed. That’s the small, the short-lived branches. Then there is the long-running branch concept. In bigger projects, you mostly have a stable line, maybe that’s the master branch, and don’t ever commit directly on the master branch. This is dangerous because it’s production code and below that come all the feature branches. So it’s really a hierarchy and those long-running branches are there during the whole project. So you have a master for production and a development branch, maybe another testing branch or something, and then the short-lived topic branches. So these are two very common workflows that I often see with people. That’s very common in the wild, actually.

    Jen

    Yeah, and then I’ve also seen tagging put on top of that. So that if there’s, say… like you just said, there’s feature branches and then there’s a main development branch that sticks around longer and then there’s a stable line that people use tags to say, "This is the 0.4 release and the 0.5 release and the 0.7.4 release and the…" just to kind of mark little flags in the world of, like, "Ok, we actually pushed that to the world."

    Tobias

    Yeah.

    Jen

    I mean, what do you think is tough about that? Where do teams fail in figuring that out… it just seems so controversial and, like, nobody’s quite sure that they’re doing it the way that they want to, or nobody’s really quite sure how they’re supposed to do it, or…

    Tobias

    Yeah, yeah. I think people coming from different backgrounds, that’s one problem. So having a very complex branching workflow with a team of lots of designers is just probably too much and a bit overkill, probably. But on the other side, the CTO might want to have his reasons for thinking about a complex workflow. So I think it’s important to find a balance in the team. Don’t make it too complex and on the other hand, I think, I said before, people do have to learn the basics of Git. So even if they come from years of experience in version control and they think they already know how things are going, chances are they might not. Because Git is a bit different and, I said before, branching works a whole bit different than in other systems. It’s really worth to take the time and get the basics right. I think that is one of the problems.

    Jen

    Yeah. Will you talk a bit about how branches are different than forking a repo and submitting a merge, a pull request, kind of workflow?

    Tobias

    Yeah, sure. So forking a repo is actually making a copy of the repo. In contrast to that, branching is just on the repo level. If you’re creating a new branch, it’s just a new context inside of that repository. And in contrast, if you’re forking a repository, you’re making a complete copy of the whole repository. These are different levels of action, actually.

    Jen

    Yeah, I mean, it feels like I see it mostly in open-source projects. Where you don’t give the whole world access to the original codebase. You give them the opportunity to fork it. Why is that being used as a workflow instead of trusting people to actually be on the one and only main, the real repo?

    Tobias

    That’s a valid question and I can’t provide an answer to that. [Both laugh] If there are really complex projects, of course you’d have to take, well, complex workflows, but in most cases, I think, this would be inside of a one in the same company, it would be overkill, I think. Because as you said, you can do a lot with branches, with simple branching inside of one repository. If you have a bunch of high-class nerds, that might want to use that workflow. It’s, of course, definitely a valid workflow but I think not necessary for most cases, let’s say it like that.

    Jen

    Yeah, I mean, it’s cool. It’s really cool that Git has all these tools and has all these powers because then you can just kind of figure out, you know, you can do whatever you want. You can do whatever you think is best for your team. Even when your team is just one person. That’s another thing that I find interesting, is that Git can be extremely useful even if you just have one person or maybe two or three people working on something and you have a tiny little team.

    Tobias

    Yes, absolutely. This is not a big team issue or a big team tool. You get all the benefits of using version control by yourself. Being able to roll back to recover from mistakes. That will happen. This is the most important thing, I guess. Being able to experiment safely in your own project, even if no one else is affected by your mistakes but yourself. It’s still worth being able to recover, to undo. That’s the reason why version control is important.

    Jen

    So let’s talk about that. ‘Cause that’s another place, I think, where I stuck, I think I’m sure other people get stuck, right? I can say all these wonderful things about how awesome it is and how you can always roll back and you can recover work and blah blah blah. But then the truth is, when I need to roll back and I need to recover work. [both laugh] frequently I’m lost. I’m like, "I’m really glad that that’s there, but I don’t know how to get to it." Or, "I think I know how to get to it, but I’m getting… I’m confused." Or, you know, why do I want to use Git revert vs Git reset vs Git clean? And when do I need to use —hard? Usually, I’m just like, "Undo the stuff that I did and take me back in time." I want the Git take-me-back-in-time command. Like, where is that? [Tobias laughs] So can you talk about, how do you get back? How do you recover? What are some of these options? When do you use one versus another one?

    Tobias

    Sure, that’s a great question. Because indeed there are a couple of different ways to undo. It’s a broad term, so, yeah. Let’s start with the most basic distinction. You can undo uncommitted local changes in your working copy and you can undo committed changes, older revisions and so on. Let’s look at the first case, first. Undoing stuff that is not committed yet, that is local in your working copy, local changes that you just made, is, well, the easiest thing to do but also the, well, the only undo action that you cannot undo. If you’re discarding local changes, you should be damn sure. Because you cannot undo this. The reason for this is, it has never been committed to the repository. It’s not saved in Git’s great database and if you undo local changes, they’re gone. This would be on the command line, the Git checkout command. Same as switching branches but the two dashes, sorry about that, I didn’t design Git. And there’s the other type of undo that deals with committed changes. Commits that have already been recorded in the local repository. There are, I would say, two main commands to do that. There is a Git reset command and a Git revert command. Actually the distinction is easy. Let’s see if I can tell it in an easy way. Reset really takes you back to a certain revision in your repository. If, let’s say, you’re rolling back with the revert command, sorry, with the reset command, by five commits. These newer four commits are, essentially, gone. You could recover, in theory, so there’s nothing lost if it proves wrong. But essentially they’re gone and you’re at commit number, well, n-4. Revert, in contrast to that, just takes one commit and reverts its effects so nothing is deleted by a revert. Let’s say you have one commit in the middle of your repository and you know the changes you made in that commit are bad. Everything else beyond that point was fine but this commit in the middle is bad and you want to revert its effects. That is the case for the revert command because revert creates a new commit, actually, with the opposite changes. So if I deleted a line in that old commit, the Git revert commit will create a new commit that re-adds this line. This is the distinction between reset and revert. Could I shed a little bit of light on this?

    Jen

    Yes.

    Tobias

    Oh great.

    Jen

    Yeah. And I think, um. Yeah. [Tobias laughs] I don’t know what… I mean, I’m having a hard time remembering just personally why it’s so hard when I was doing everything on the command line several years ago. What’s the —hard and…

    Tobias

    —keep. Yeah.

    Jen

    Yeah. So explain those extensions.

    Tobias

    These flags are for the reset command. So if you want to roll back to an older commit, you have a hard option, you have a keep option, you have a soft option, so there’s lots of options. The main distinction between hard and let’s say, keep, is if you say hard, the changes made in between are really, well, swept away. So you’re having a clean working copy after that, no local changes, and you’re at that old commit. If you use the keep option, the changes in between, let’s say, the new changes containing these commits will be preserved and restored as local changes in your working copy. You will have all the stuff that happened afterwards but not committed anymore but as local changes. That’s the main distinction. In most cases, I guess, you will want Git reset hard because that’s the cleanest and the easiest way. But also, kind of destructive. Yeah.

    Jen

    Yeah. One kind of just… I mean, it’s interesting, ‘cause sometimes you just know. Maybe it’s different for other people, but for me, the most common situation I find myself in, is one where I know I want whatever the thing is I’m trying to get rid of, to go away. [Both laugh] Like, there’s no doubt it needs to go away. And I want to be able to kind of start over.

    Tobias

    You’re one step further than me, in most cases, because I have a hard time figuring out what it is that has to go away.

    Jen

    Right. Well, that’s a different show. [Both laugh] That’s a different episode on how to find bugs in code. I think it’s sometimes ‘cause you don’t know what you’ve done and you just want to, like, undo it all and just do the thing that you were trying to accomplish in the first place. You want to attempt to do it again from the beginning. I think it depends on what you’re writing code for. I think there’s some situations where that’s a complete waste of time and if you’ve been working for four hours, you want to keep four hours of work and just, you know, alter 15 minutes of work. But sometimes, I think, maybe it depends on what kind of code you’re writing, but you want to just get rid of those last four hours, have the experience as a human and the knowledge that you’ve gained doing it wrong. But then, you know, be able to just start fresh and write the code cleanly from the beginning the way you would have had you been wiser four hours prior.

    Tobias

    Yeah, yeah. That’s also another case for branching, actually. You might even get away with, well, deleting that branch because it’s cheap and easy and creating a new branch and starting from a different starting point, actually. That’s another classic example of branching where it makes things easier.

    Jen

    Yeah, and you know, I think… it’s vaguely coming back to me. The moments when I’ve really needed these commands the most have been when I’ve had merges go bad. I realized that merge… my attempt to do a merge to solve a merge conflict went really badly and I just want to not have that be around. [Both laugh] And go back to the beginning when I needed to solve the merge conflict and try again. So will you talk some about merge conflicts and what they are, why they’re hard?

    Tobias

    Actually, let’s start by saying, they’re actually not hard. [Both laugh] That’s the feeling that I want to leave you with. Conflicts are actually easy to understand. It’s only in most cases, Git can merge, Git can integrate most stuff by itself. The cases where you have a conflict are rather rare. And the case is you and a colleague or you and yourself in another branch changed the exact same line in the exact same file. Actually, this shouldn’t happen all that often. And if it does, you might want to talk a little bit more and see if it’s really necessary that you’re working on the same piece of code at the same time. This is something to talk about. When it comes to a merge conflict, the important thing to remember is, you can always start over. There is nothing lost. You can always play that game once more and see if you make it to the end. I guess that’s the most important thing to remember. You can’t mess up in that situation, actually. If you do, start over and re-do the merge, as you said. And then it’s really just thinking about, you have two, in most cases, you have two versions of a file that clashed. Well, which version do you want to use? The left one, the right one, or is it a mixture that is necessary? That’s really… there’s no magic in that. It’s looking at the files. It’s looking at the solution. And it’s, well, the only person that can say what is right is you or your colleague. This is actually programming again. You have to decide how the correct solution should look. That’s a thing that Git can tell. I said, it’s not magic, it’s just, well, trying to figure out what is right. The last part is stating what is this right version or editing it until it’s right. That’s actually all.

    Jen

    Yeah, I think the thing that made merge conflicts so hard and so frightening is a lack of great tools several years ago. And understanding that there was some kind of… and also, really, not knowing what a merge conflict was. I mean, knowing that something crashed into something but I don’t know what that is. And then, I’m supposed to tell it which one I want and I don’t know how to know that ‘cause I can’t see anything and I don’t know what to say in order to tell it, even if I could, even if I did know, right? So all of that has been solved and I think a lot of it has been solved by better tools. Part of it is understanding that, as you said, a merge conflict is where two lines have been changed separately but sort of at the same time and the computer’s not smart enough to know which one it should use. In a normal situation, it overwrites the old one with the new one. But if there’s two new ones, if there’s one old one it’s supposed to overwrite, and there’s two new ones, it’s like, "Well, which new one do you want me to use? You need to tell me." But then the tools. I mean, this is where back in the day, especially SVN days and stuff, I had a tool called DeltaWalker that was like, "[Trumpet noise] Get out DeltaWalker!" [Both laugh] I always thought of some opening of some TV show with, like, a cowboy or something. I don’t know, or maybe a space robot or somebody marching into the rescue. ‘Cause it would give you graphs. It would give me a visual, like you said, a left and a right and it’d show you, there’s two new versions. This is one and this is one and there’s a button that says, "Which one do you want?" and you can say, "That one, this one, that one, this one, this one, this one, that one." And then you can push the button at the bottom and then you’re done. When there’s a tool like that, it’s not hard or frightening. And that’s what I’ve been very excited about using Tower for most recently. It feels like you grab some kind of a GUI so that you can really see what’s going on. And then it’s really not that scary.

    Tobias

    Yeah, yeah. The point is visualization, I guess. Making things less abstract because I exactly know what you mean. When I started working with git, a merge conflict was scary as death. I never knew what was happening. That was the frightening part. As soon as I understood, well, it’s two versions of a file that, well, I have to figure out. Do I want to use the left one or the right one? Or do I have to edit them to make the solution correct? There will not break anything if I do this or that? I just have to decide. Making this decision, this fact of the situation visual, is, I think, is half the way. Because people begin to lose their fear of the situation. That’s all. Because the situation itself is not that difficult.

    Jen

    Well, I also think that the fear came from any of us who used CVS or SVN. [Laughs]

    Tobias

    Oh yes.

    Jen

    Because there was great reason to be very afraid. [Both laugh] You probably, it was probably going to end with a phone call to the dev ops people and maybe taking out the repo for the entire team.

    Tobias

    Shut down the computer and run, run, run, leave the country! Yes. [Jen laughs]

    Jen

    Like, maybe you were going to

    break everything and it was going to take two days to fix it. Maybe you were gonna wipe out your colleague’s work and maybe…

    Tobias

    Lose your job, get homeless, and everything else. Just because of a merge conflict. That’s… oh yeah. Absolutely. [Jen laughs]

    Jen

    You’re going to lose your house. [Both laugh]

    Tobias

    If you’re lucky.

    Jen

    It’s gotten… it’s not that bad now. Git it not nearly as punishing as those older systems. I think there’s so many great tools out there today that it makes it much easier. And perhaps this is the one thing that a lot of people who do stay on the command line most of the time go ahead and grab another tool for, is merge conflicts. Because it’s so much easier. I mean, I’ve opened up the text. You can open up the code file and it says in there, there’s like a bracket bracket bracket bracket bracket bracket head bracket bracket bracket bracket. [Both laugh] And you’re like, searching for these markers in the code that Git has dropped in there to say, "This is where there’s a problem. We’ve surrounded the problem with this special robot code to show you where you need to…" And you can do it that way, but it’s easier when you don’t have to.

    Tobias

    Yeah, and understanding what this robot code - that’s a nice term - what this robot code does, and that it’s not magical. You can remove it, save the file, and say, "Well, that’s my resolution." Or you can leave it in, even, and you have strange characters in your resolution. It’s just a text file. Well, no magic. That’s good to know.

    Jen

    Yeah. So let me jump in here with our first sponsor today. Atlassian BitBucket. Atlassian is the company that makes JIRA and Confluence and some other tools that maybe you’ve used if you’ve worked at a big company. I’m actually a huge fan of their redesigned JIRA that they did just last fall. JIRA Agile is the new version or they also have a Kanban version. But I’m kind of completely in love with it. So I was talking to Atlassian and they wanted to tell you today about BitBucket. BitBucket is their space up in the cloud where you can store your Git repos. A show about git, they were like, "People should know about the BitBucket." This is a great place that you can use to share code, to keep your remote repository where you can collaborate with team members. You can add people easily, giving them permission to clone the repo and make changes and push those changes. You can see pull requests. People can submit pull requests and then the person who’s in charge of, you know, doing code reviews can go ahead and review it and see the code right there on their website and pull it. All the kinds of things that you might want from a remote repository, website-based kind of application. BitBucket is cool because it’s, you know, Atlassian has really been serving large corporations and enterprise companies. Their pricing has come down, though, so now it’s a lot more affordable for people who have smaller projects or smaller companies. But they have experience with big, high-level complicated security. Which is always needed on big projects. And they also offer, in their pricing scheme, you can go get unlimited private repos for whatever your, whatever pricing level you’re at. You can have unlimited numbers of private repos. And if you just have five users, so if you just have five people working on a particular repo, you can get a free account. Totally free. Or if you’ve got 10 users, it’s 10 bucks a month; 25 users, 25 bucks a month, and up from there. But it’s actually a really good… you want a place to store private repos that’s just free, go check out BitBucket. But also they wanted me to tell you about these tutorials they have. If you go to atlassian.com/webahead, it’s A-T-L-A-S-S-I-A-N dot com slash webahead. They’ve got a bunch of tutorials over here. Very succinct. They’re really cheat sheets, in a way. They’re short. They just walk you through a command and tell you exactly what it does, little diagrams to help you understand the mental model of what it’s doing. I actually was using these as cheat sheets the other day when we were recording this show, to help me remember the words like, let’s see… undoing changes, they’ve got a whole page on undoing changes. Like Git checkout, revert, reset, clean. Those kinds of words, you know, when you’re, like, on the command line and you’re trying to remember the thing that does the thing. atlassion.com/webahead and you can check out their totally free little guide over here on how to do migrations, resources for learning Git. They’ve got some videos. So, thanks to them. Thanks to Atlassian for supporting the show.

    Jen

    So, ok. What’s next? Oh, here’s a question from Larry Garfield. "Tell people about git add -p. It’s the best thing ever." What’s git add -p?

    Tobias

    Yeah. Well, let’s start with what git add is, actually. In Git you have to tell the system which changes you want to have in the next commit. Just because something was changed locally, doesn’t mean it’s in the next commit automatically. So this is great for making granular commits because that part is important because just cramming all your local changes that you have since a week into a commit is not useful version control. So keeping commits small and focused on a topic is important. That’s the Git add thing. And git add -p is a way to make this even more granular. P is for patch. It’s for smaller things. You can even add parts of a file to the next commit. You might have some changes at the top of the file that belong to one topic and at the bottom of the file you have another set of changes which belong to another topic. So if you’re a good version control user, you’ll make at least two commits with these different topics and with git add -p you can say, "I want that part of the file, that part of the changes, in my next commit." Commit. Go on. And after that, maybe modify the files some more or discard the changes or simply add the rest of the file to the next commit. So that is git add -p.

    Jen

    Nice. I do that a lot. Because I’ll… [laughs] In fact, I actually, one time, I… I work a lot in Drupal, I work a lot in Drupal front-end development, writing a lot of CSS for themes for Drupal. And when I’m working by myself on my own projects, I have, in the past, tended to do things like, just make a commit that’s like, everything from Thursday. [Both laugh] Or a bunch of changes. A bunch of changes. [Laughs]

    Tobias

    That’s a very popular workflow, actually. The most popular, I guess. And it’s understandable.

    Jen

    It’s terrible! [Laughs]

    Tobias

    Yeah, but we’re all used to that kind of workflow.

    Jen

    I know, it’s so bad though, that the folks who… I’m a big fan of Pantheon and I host a lot of sites on Pantheon and it was so bad that, in fact, like, way back in the day when Pantheon was still new, one of the founders pinged me one day and he was like, "What’s up with your commits?" [Both laugh] ‘Cause I think I had asked about it. I was having a support problem and I asked the question and he looked at my commit log and he was like, "What?"

    Tobias

    I call that a wake up call. [Both laugh]

    Jen

    He shamed me into… [laughs] But now that I’m trying to do much better, you know, of course. [Coughs]

    Tobias

    Sure, sure.

    Jen

    You know, I’ll have a CSS file that’s maybe page.css or typography.css where all the typography for changes go. All the CSS for the typography goes. But I’m actually working on, you know, this particular thing and that particular thing. And it’s really nice to be able to just go and clickity-click and, look at that, Git Tower GUI, and be like, "Ok, these lines," like, "I should have made a commit earlier and I didn’t. I moved on to this other thing, so let me go back and cherry pick through and find the lines of code that belongs to that thing I was working on this morning and then I’ll make a new commit with the stuff I’m working on this afternoon." Especially when I’m working by myself and I don’t have tickets for all of this. I don’t have user stories for all this stuff. So I’m not consciously moving from one user story to another user story or one task ticket to another task ticket. It’s just sort of bubbling out of my chaotic brain.

    Tobias

    Yeah, that’s natural. When you’re working, you can’t just reduce yourself to just one topic. You see another line of code that might be good to change in that context, too, so you branch out a bit and do this and that. Later when it comes to wrapping the stuff up in nice little packages, that’s the point where you should get tidy and make small commits.

    Jen

    Yeah. So let me ask you about remote repositories. Because… so back with the SVN world. And I don’t want to get into SVN too much, because I feel like SVN is over.

    Tobias

    Thank you. [Both laugh]

    Jen

    There was this model in which there was a, kind of a master robot, like headquarters where everything lived. And you, as a lowly human, were just gathering some of the code and some of that information on your local machine. You’re making changes and then you were pushing those… that’s not the right word, but you were, whatever, shoving those changes you made back to the robot headquarters. One of the beautiful things about Git is to just sort of wipe that model off the board. Where every instance of the repo is, in fact, a clone of robot headquarters. So if I’ve got a laptop and there’s four other people with laptops and then there’s, I don’t know, the main computer in the office, and then there’s the live web server, and there’s the whatever, wherever we’ve decided to put this thing. Our remote backup in another country or something. We… all of those sort of equally important as all of the others. Any of them could get wiped out and any one of them could become the sort of new, official… and it seems like… new, official robot headquarters. It seems like there’s a… even though all of them are equally important, there is a convention that has carried over where… I guess it’s theoretically possible, say, for three developers to be working on a project together. It’s not going to be on a live web server yet. Maybe it’s not even a website. Maybe you’re making a native application or something. It’s a piece of software that you’re writing. It could be where all three developers have laptops and they just push their changes to each other and there is no central place where everything’s saved. But that may or may not work because… this is where my understanding starts to break down, and I want you to correct me if I’m wrong. It seems like if everyone closed their laptops at the same time, you know, or one person’s awake and working and they’re trying to shove their changes to everybody else but those guys are offline, and this person’s over here and she hasn’t gotten the changes because that person over there is offline still. It seems like there’s a culture-way to work where there is a sort of central, remote repository where… that’s always online. Just for the sake of it always being online. And it’s, I don’t know, the main backup or something. Or it’s the main place where it lives. And that’s where people use things like BitBucket or GitHub or set up their own servers to be that place. So will you talk a bit about the remote repository situation? What works or doesn’t work as a remote repository? And this idea that you don’t necessarily need it? Or maybe you could have more than one. Like, you could put it on GitHub and on Pantheon and on BitBucket and on a backup server of your own choosing. I think. Is that right?

    Tobias

    Yeah, that’s absolutely right. I would have interrupted you. No, everything is correct. The main thing with remote repositories is, it’s a means of exchange. You need a place, a central place, to collaborate. That hasn’t changed from the Subversion days, actually. But the thing with Git and other… that’s a decentralized part of a distributed version control system like Git or like Mercurial, is you’re not depending upon such a remote repository. You’re completely independent of any remote repository. You can do, I guess, 95% of work offline on your own computer. So if you don’t have a connection, if you’re in the train or something, you can commit, you can add stages, add changes to the staging area, you can even look at the project’s history because what you have with a clone, with a local version of a remote repository, is a full-blown repository. There is no more first-class and second-class repository thinking because they’re the same, actually. The only thing that’s different between the remote repository and a local one is you have working files on the local one. That is all that there is to it. The objects are exactly the same. It’s just that in local case, you have a working copy of working files, and in a remote repository, you don’t. You just have the Git repository, just the Git database, let’s say it like that.

    Jen

    What do you mean by working files? I don’t know what that means. What do you mean?

    Tobias

    Your project files, actually.

    Jen

    You mean files that you’re editing? Your changing files?

    Tobias

    Yeah, yeah, yeah, your actual files that you’re working on. So if you’re having a web project, those CSS, HTML and PHP files lying there. Inside of that project folder, you have one little hidden .git folder and this .git folder is actually your local repository. Inside of that, this is the place where the magic happens and this is also, this could be a remote repository. Your HTML, PHP and other files are your working files and that little .git folder is a repository.

    Jen

    Are you saying on the remote, that the remote only keeps the .git folder and then it doesn’t have the other…?

    Tobias

    Yes, yes, absolutely.

    Jen

    But why? What’s up with that? Wait, I didn’t know… I never knew that. So if I somehow, you know, SSH’d in to a remote repository server and looked at it, you would see the .git file, which contains all of the information to be able to create these files and roll them back in history and such. But the actual files themselves wouldn’t… you wouldn’t see them sitting there in the file system?

    Tobias

    Absolutely correct, yes. That’s why remote repositories are sometimes called "bare repository" because they lack a working copy. That’s the reason. So, yeah, you only have those versions in that kind of database and could, well, you use it to exchange files. If I upload a version, if I push some new commits to that remote repository, the remote repository receives the changes and saves the new commits, but there’s no use in having a working, the name it, a working copy. Because no one should work on the remote server.

    Jen

    Yes, please.

    Tobias

    Mmm hmm. [Jen laughs] Don’t FTP into that server and change things.

    Jen

    Drives me crazy when there’s someone on the team who does exactly that. They FTP, or more commonly they SSH into a remote something or other. Maybe not the… I guess it’s not the remote Git.

    Tobias

    Well, it’s so comfortable, but yeah. No.

    Jen

    They SSH into the dev server, they edit files on the dev server, and then they don’t put them into Git.

    Tobias

    Mmm.

    Jen

    So that when you go to pull, you’re not pulling their changes and you can’t figure out why the dev server doesn’t match your local server. Oh, it’s because they edited files on the dev. [Whispers] Don’t do that. I’m going to come haunt you.

    Tobias

    Those are the colleagues that don’t live long.

    Jen

    Man, those are the… oh, man. Ugh. Having flashbacks. [Tobias laughs] So a dev server… say you’re working on a website. A dev server, a testing server, a staging server, a live server, they all have working copies of files because they’re running… you can go to the URL and you can see the web server running, right? So you’ve got those files. But a remote server is different in that those files have been told to not be there? To go away?

    Tobias

    Yeah. Actually, even in the case of the dev and production server, you strictly don’t have a working copy in the version control sense. What you should have is a mechanism, a deployment mechanism, that checks out, that gets files from the repository and puts them into your… wherever you want them to have. But this should really be separate. This is a place where people mix up version control and deployment and these should really be kept separate. One thing you could use to make that happen is hooks. Hook scripts in Git allow you to do something when something else happens. For example, let a script run that gets the latest version from the repository and puts it, copies it to your web server location when a push happens. When somebody performs an upload. This is really a deployment workflow. This should be kept separate from version control.

    Jen

    Yeah. Yeah. When you’ve got people who have the skills to do that. Or when you have a big enough project that it’s worth doing, taking that extra effort, I think, in my opinion. And sometimes I feel like with smaller projects, it’s a layer of complexity that’s not necessarily needed.

    Tobias

    I feel it’s still too complicated. I feel it’s still like version control was five, five to 10 years ago. I think this should change and I guess it will. Well, who knows.

    Jen

    Yeah, yeah, deployment’s a whole other… something. I don’t know what the word is.

    Tobias

    [Laughs] Something.

    Jen

    It’s just, it’s crazy how complicated websites have gotten. It just really is. Even that you have a development server and a test server separate from your live server. Even on smaller projects.

    Tobias

    Yeah, historically that’s pretty new, actually.

    Jen

    Yeah it is.

    Tobias

    We just stopped hunting deer in the forest and now we’re having development and live servers. [Jen laughs] It’s crazy.

    Jen

    Right, that’s true. We were just hunting deer in the forest two generations ago. What happened?

    Tobias

    [Laughs] And now there’s live and development servers.

    Jen

    Yeah. Alright, let me jump in here with our other sponsor. Then I’m going to ask you about sub-modules. So get ready. [Laughs]

    Tobias

    Oh, I’m gone, I think. [Both laugh]

    Jen

    Stick around. So let me also tell you about Squarespace. The all-in-one platform that makes it fast and easy to create your own professional website, portfolio and online store. Squarespace, I once again, I had a friend who is trying to build a portfolio website really quick. And she’s also learning how to do HTML and CSS and so I was telling her all the different options. You could use this software, open-source software, or she could build everything by hand and FTP it up or she could just go to Squarespace and focus on the content. Make sure she’s got really good pictures and really good, you know, writing about herself, promoting herself, and get all of that on the website. Sometimes it’s just faster to just use software that’s powerful and has all the features that you want. Like, "Oh, we need a gallery with a bunch of images and we want to be able to just drag those images over and clickity-click-click. Oh, look, now we want to make it smaller. Now we want to make it bigger. Oh, we want it to be responsive." Of course many of the people listening to this show, we have the skills to be able to do that all from scratch. But do you have the time, is the question? And is it always worth it? It may not be. And also, Squarespace, it’s been put together by so many smart people, a big team of smart people, that it’s really beautifully designed and pretty well… like, the feature set in the software that you use to add content and then the way that things are presented to your users, the people who visit your website, like, they really spend a lot of time thinking through the user experience design of all that. And they host it and they make code updates and so it’s always secure and you don’t have to worry about that. You don’t have to worry about deploying new stuff. You don’t have to worry about all the crazy complexity to some of these complicated websites that we build. So I always consider Squarespace, honestly, a really great option, especially for people who either don’t have the skills or don’t have the time to be spending on a whole bunch of details and stuff and code and this and that. I mean, you know, come on. Everybody and their brother, your family, your friends, are asking you to build them a website. You really gonna build all those websites for all of them? Uh, maybe you do for a couple of years. But then you realize, man, I need another option. Squarespace is what I tell people to do. So you can go to Squarespace at squarespace.com/webahead which pings them and lets them know you heard about their awesome service on this particular podcast, which helps us out. You can also then use the code jensentme to get 10% off any purchase. Whatever it is that you buy, you get a free trial and then whenever you decide to sign up, you get 10% off of whatever that was you spent by using the code jensentme. So thanks again so much to Squarespace for supporting the show.

    Jen

    So, sub-modules. Sub-modules seem cool. But hard.

    Tobias

    [Laughs] Both correct.

    Jen

    I want to explain what’s cool about them and I want to understand why they’re hard.

    Tobias

    Right. [Laughs] The cool part is probably easier. If you have, well, some kind of library that you want to include in a project, you have a couple of options. One is, copy the library code and commit it to your project. And the problem with that, well, many. Because you can’t stay up to date with the library. If the library advances, say you have, don’t know, a carousel for your image gallery or something and you copy the code into the project. Anytime the original developer fixes a bug or adds a feature, you’re in trouble because you have to find the new files, again copy them into the project, well, that’s tedious and error-prone, especially in bigger projects where it gets more complicated. Sub-modules are a means to include other Git repositories into your main Git repository project. This keeps it nice and easy. You can use all the Git stuff in those sub-projects, in those sub-repositories, too, so you can fetch and pull changes and say which exact version of that sub-project you want to use in your project. That’s the reason why sub-modules are cool.

    Jen

    Yeah, I… I mean, like, so, yes. We all know what libraries are anyway. But yesterday, there’s a jQuery plugin called Chosen which is kind of awesome. With the new website I’m building, there’s lots of places where it’s like, "Oh, you’re adding a guest to the website. Well, which episode of The Web Ahead did that guest appear on?" There’s a list of 78 shows, now about to be 79 shows, right? So is that a little, do you have to scroll in a little tiny box to find the right show? Or do I have a giant list of checkboxes that takes up five inches of the screen? This is a little jQuery plugin that kind of turns that select list into a much, much better thing. Like it just makes it way easier to use it, right? Who knows, there could be a bug, or when the new version of jQuery comes out maybe something breaks or maybe there’s some kind of a something, they realized, "Oh, we could write this better, let’s re-write the code." I’m probably not gonna know about that. I’m probably not gonna bother to go back and check every six months to see whether or not this plugin has been updated. And maybe I don’t need the changes but… the other use case, the real use cases that I totally want to use it for, sub-modules, is, again, with Drupal, you create a theme, but you can also have parent themes. And so I want to have sort of the Jen-Simmons-thinks-Drupal-should-be-done-like-this parent theme that I use across a whole bunch of different websites. Where I can add in all this code that kind of wrangles Drupal and changes things that I always want to change on every single project. And then have a child theme of that and have the child theme be, like, ok, the theme for this particular project with the look and the feel and the typography and the specific CSS for this website. And then I want to be able to make changes to that sort of Jen-Simmons-master-theme and pull it in five different websites all at once automatically. Instead of having to copy and paste the changes, you know? And be like, "Oh, right, ok, well, I changed it over here. And then this site I haven’t worked on in a couple months, I should copy those changes from that one over to this one. And, wait, where’s the… oh, I just totally fixed this bug already, where’s the… which repo, which project is that in? Oh, it’s in that one." That’s what I’m doing right now, is manually moving all that stuff around when I’d like to use Git for that and to have one Git repo that has my master theme in it and then pull that repo and put that into the repos of all these other projects that are the Drupal projects with the Drupal codebase and all the modules and the themes and everything. But I’m not able to do that because there’s no sub-module support on my dev live testing server platform. And the reason there’s no support is because apparently it’s also very dangerous and very hard. How is it that you can really create a black hole in the universe with sub-modules and explode everything? [Both laugh]

    Tobias

    Let’s say sub-modules are a little bit touchy. I would say. [Jen laughs] It’s true that managing them is not really easy. I can’t tell you a concrete reason, it’s just a bit complex. Initializing them is easy, but then managing them and keeping them up to date and on the right version and if new changes drop in, that’s not exactly easy. To be honest, I wouldn’t know how to do it on the command line. No chance. I would have to learn this, too. That’s actually where I need, desperately need, a visualization in a desktop GUI like Tower. I’m lost without that. So, yeah, they’re touchy. And I think you really need to need them to justify using them. There are a couple of cases but if you can get away without sub-modules, that’s fine. Just because you could use them, doesn’t mean you don’t have to. But anytime you’re reusing code, so the examples you made are exactly cases for sub-modules. If you want to reuse code or include code from a third party, that’s probably calling for sub-modules.

    Jen

    Yeah. And there’s something about third party code that maybe you don’t necessary want to update it. But there is definitely something about your own reused code that it feels like, you know, there’s an efficiency there. Having some sort of version control across projects would really help. But, yeah, I mean, that’s another reason that I do like using Tower or advocate for GUIs in general, is that… well, not all of them. But most of them. The good ones and Tower is definitely, this is true of Tower, like, it lets me try things that are more dangerous and edgy and maybe require a certain level of Git mastery that I don’t actually have. It lets me try them because I have faith that the tool is going to keep me from doing something dumb that I can’t… things like, I want to push but I didn’t commit things yet. Or I go to pull but I haven’t… you know, simple stuff like that. It just reinforces the proper workflow in a way that the command line is a little bit more, "Sure! You want to do that? I’ll do that for you." [Both laugh] It’s a little bit more of a babysitter and it’s a little bit more like, "Eh, you probably don’t really want to do those four things in that order. That’s not going to work out. You need to… here, let me show you a graph of what you’re trying to do. That’s not a good idea."

    Tobias

    Take off the helmet, it’s not necessary.

    Jen

    It feels that way, but it feels like it’s really, it helps keep you from doing something stupid. Which is why I got all excited about sub-modules, like, I don’t know, a couple years ago when I heard about them for the first time. I was like, "No! Let me use them! I know I won’t do anything wrong, ‘cause I’m using these super powers that are protecting me from being stupid." I don’t know if that’s true or not, but I felt that way. But I couldn’t use them anyway.

    Tobias

    That’s probably good to know that I even I have to use in that use, is a GUI and Tower, because, well, I’m half a developer or a third a developer and some stuff is just too complicated for me. I know where to keep my hands off the command line and what I can do on the command line and for some things I just need, desperately need visual aide, and sub-modules are one of those topics where it gets easier. Sub-modules are one topic that is not… I could be hanged for saying this… it could be better in Git. It could be better implemented. It’s really a bit complex and, yeah, we’re trying to make that smoother in Tower. That’s our mission, if you want.

    Jen

    What’s another thing about Git that a lot of people don’t use but is there and it’s powerful and kind of awesome if you’re up for the challenge?

    Tobias

    I suspect that stashing is not that common. Or if you’re starting out with Git and coming from Subversion, the stash is a completely new concept. Essentially it’s a clipboard for local changes. Imagine you’re working on some stuff and a bug report comes in and you have local changes that you don’t need at that time. You need a clean working copy to, well, create a new branch for the bug fix or switch to another branch or roll back even and undo things. But you don’t want to lose your local changes currently. So the stash is something you just use to take those changes and put them on that kind of clipboard. That’s pretty new to most people. And, I guess, the topic that Gregory, was it, that asked git add -p? I don’t remember.

    Jen

    Oh, Larry Garfield, yeah.

    Tobias

    Oh, sorry. Yeah, Larry. So staging parts of a file, even single lines or chunks or hunks, that is special to git, too. And, well, after some time you really can see the value in that. At first it might be overkill but it definitely is a great thing to do.

    Jen

    I guess most of what people could do to get better at Git is get better at the human side of it. The culture of making good commits, using branches, organizing things nice and clean and neatly. Writing good commit messages.

    Tobias

    Yeah, that’s also the possibility for people to… and I really mean that, to become better developers. I really notice this with myself. I became a better developer by using Git. I made commits that made sense and that made things easier for the team, that made things easier to understand, even later. These are all things that really help a development process. Git itself, or version control, is not a reason for using itself. It has to bring value and that is, in my opinion, it’s more quality and, well, growing as a developer.

    Jen

    I was watching some, you know, cooking reality TV show lately. Or maybe it was a documentary, actually, about professional chefs. They were talking about how, like, a really great professional chef will run a kitchen in a certain sort of way. Where things are very well-organized and very clean and when they prepare the food, they’re spending two hours in the afternoon chopping up vegetables and such and putting things, that they’ll… there’s a certain kind of… a great, a well-run kitchen will frequently be extremely organized. Where the salt and pepper is always in the top right corner of the table and the vegetables are all lined up in this very particular order and they get lined up that exact same way, day after day. And that the person working on the fish station or whatever, has, like, their tools are set up in this particular way and that they’ll get a ticket and they’ll cook that table’s dinner and then they’ll clean and then they’ll set up for the next ticket. Very quickly, I mean, extremely quickly. But that there’s something about the art of being organized and being clean and being, just, it’s… I mean, people call it anal retentive for something, but there’s just this way of being, of holding up that kind of organization as important to the quality of the outcome and as part of what it means to be a professional what of what it means to be a master at that particular craft.

    Tobias

    Yeah, yeah, absolutely.

    Jen

    And I feel like there’s a way in which that applies to being a developer, as well. Between Git and the way you organize things in Git and branches and the commit messages and, also, the way that a team runs its tickets. That having really well-written user stories and a very strong discipline around tasks always being part of user stories and that you don’t have these extra tasks floating around and that you only work on the stories that are in the current sprint and that your bugs are actually really bugs, they’re not sort of secret feature requests.

    Tobias

    Yeah, yeah. Keeping the chef image for just a second, it’s not about, it’s not only about the cooking. It’s the tools and the workflow around that make it efficient and good in the end. Agreed.

    Jen

    Sharp knives and a clean table and really nice quality vegetables.

    Tobias

    Just like with developing, yeah. Good vegetables.

    Jen

    No more Cheetos. [Tobias laughs] Soda and pizza. So, oh! And you also have… let’s tell people about the Learn Version Control with Git Step-by-Step Course for the Complete Beginner.

    Tobias

    Yeah, yeah, yeah. We made a… well, we’re pretty close to people learning version control, as you might imagine. We noticed there’s a lack of documentation or of learning resources for not so technical people. If you have a master’s degree in information science, there’s lots of books for you. But if you want to start as a designer or a web designer or a project manager and get our head around Git and version control, there’s hardly any learning resource for you. We started with that in mind and created a free online platform with an eBook for these people. So, for people who start out with version control, and especially with version control with git, and take them from, not A-Z but A-P, actually, I guess. From beginner to intermediate, take things slowly and really start at the beginning and show those things that are really necessary for a beginner to understand.

    Jen

    Nice. And so there’s an eBook that people can read online for free, right? Or they can buy an eBook that also comes with the tutorial video that goes… like, that you can read on a Kindle or an iPad.

    Tobias

    Absolutely. You don’t have to spend a dime to get started with Git. You can get that eBook with the video but not necessarily. So you can learn for free on git-tower.com/learn.

    Jen

    Nice. And then you have a video course coming out soon?

    Tobias

    Yes. Well, soon is a matter of definition. [Jen laughs] I’m working on it. That’s probably good to know and good to say. We’re working on it. We want to make it a great video course so taking small steps in each video and a couple of videos, not just a two hour series, but something small that takes people from step to step. That’s coming out soon.

    Jen

    Nice. And if people want to learn more about Tower, they can go to git-tower.com.

    Tobias

    Absolutely.

    Jen

    And check it out. And you just came out with version 2. What do you think are the biggest differences between version 1 and version 2?

    Tobias

    Well, we smoothed out the sharp edges in version 2. We really wanted to focus on making things easier, on making workflows easier for people. Features, of course, you have to have a lot of new features in a major upgrade. That’s a case. But the important thing for us was really to make Git easier than with version 1 and already there, this was our motto that we lived up to. Just as an example, we introduced a merge conflict wizard. I think we’re the first application that features a visual way to deal with merge conflicts. That’s typical, I guess, for the software, or for our thinking. Another thing is we integrated with the big code service, the code platforms, like GitHub, BitBucket that you had a sponsor, and Beanstalk. We’re really ma

    —Huffduffed by cdevroe

  3. The Web Behind with Tantek Çelik | The Web Ahead

    Eric MeyerEric A. Meyer has been working with the Web since late 1993 and is an internationally recognized expert on the subjects of HTML and Cascading Style Sheets (CSS). He is the principal consultant for Complex Spiral Consulting and lives in Cleveland, Ohio, which is a much nicer city than you’ve been led to believe. A graduate of and former Webmaster for Case Western Reserve University and an alumnus of the same fraternity chapter to which Donald Knuth once belonged, Eric coordinated the authoring and creation of the W3C’s CSS Test Suite and has recently been acting as List Chaperone of the highly active css-discuss mailing list. Author of "Eric Meyer on CSS" (New Riders), "Cascading Style Sheets: The Definitive Guide" (O’Reilly & Associates), "CSS2.0 Programmer’s Reference" (Osborne/McGraw-Hill), and the fairly well-known CSS Browser Compatibility Charts, Eric speaks at a variety of conferences on the subject of standards, CSS use, and Web design. For nine years, he was the host of "Your Father’s Oldsmobile," a weekly Big Band-era radio show heard on WRUW 91.1-FM in Cleveland.

    meyerweb.com@meyerwebon wikipedia.org

    http://thewebahead.net/46

    —Huffduffed by cdevroe

  4. Git with John Albin Wilkins | The Web Ahead

    Jen Simmons, host and executive producer

    As a full-stack designer since 1996, with expertise in HTML & CSS, my projects include front-end development work for CERN, design work for Google and the W3C, and clients from Mark Boulton Design to the Annenberg Foundation. My career has been an eclectic blend of award-winning short films, print design, theatre, audio-mixing for live shows, and speaking. I’m deeply interested in content structure and innovating page layout. The Web Ahead was born of a desire for us to empower and challenge one another as we make the web.

    http://thewebahead.net/40

    —Huffduffed by cdevroe

  5. The Latest in CSS with Chris Coyier | The Web Ahead

    [00:18:04]Yeah, I’m like freaking out about it. [Laughs] I’m sounding very calm right now. But no, yesterday, Firefox 28 shipped. And usually I don’t pay attention to these new releases, but I’ve been waiting for 28 specifically for months because they added Flexbox flexwrap support to Firefox. So basically what that means, because not everybody who listens to this show is a developer, it’s just a show for all sorts of people, you could do this layouts with Flexbox. I’ve worked as a developer where you get a design from a bigger team, perhaps from an outside agency, and they mail over these PDFs and some of the details in those PDFs in the past were literally not even possible and it would be frustrating because it’s like, why did you design this website? You’re supposed to be a professional web designer and yet some of the things that you’re imagining are not possible. And now a lot of those things, a few of those things are now actually going to be possible with Flexbox.

    And one example that people give a lot is, if you have five links in a row, in a bar, it used to be that mostly you would just end up with them kind of all squished to the left next to each other. So you could put space between them but you’d have one two three four five, they wouldn’t be centred in the width of the whole screen. Or if you made a responsive site or a fluid site where the box that they’re in grows and shrinks as the browser window grows and shrinks those links aren’t going to necessarily go closer to the right hand side they’re just going to stay together on the left. And maybe you want them to be evenly spaced all the way across. So that’s the kind of thing that you can actually do now with Flexbox and that’s been possible for a while but the things that you could not do until yesterday at least, you couldn’t have them in firefox until yesterday, was perhaps doing a whole page layout.

    http://thewebahead.net/63

    —Huffduffed by cdevroe