Podcasts about epublishing

Was lesen PathologInnen, um sich fort-und weiterzubilden? Natürlich die Zeitschrift „Die Pathologie“ aus dem Springer-Verlag. Und genau um diese geht es in der heutigen Zwei gegen Eins-Folge. Wir sprechen hierfür mit dem Schriftleiter Prof. Wilfried Roth und Stefanie Schumacher-Schmidt, Head of Journals & ePublishing 1 bei Springer Medizin. Vielen Dank an Beide für die spannenden insights! Viel Freude beim Zuhören! Hier der link zum Journal: Home | Die Pathologie   Wenn ihr uns etwas mitteilen wollt, schreibt uns gerne! sven.perner@pathopodcast.de linkedin.com/in/prof-dr-med-sven-perner-6a771b48   christiane.kuempers@pathopodcast.de linkedin.com/in/pd-dr-med-christiane-charlotte-kümpers-279a382

Greetings Glocal Citizens! Ten years on, after the Arab Spring bloomed, we're taking a virtual tour to Tunisia. There I met with Nadhir Douma a ICT specialist with an eye on continuous improvement of the human condition. Born and raised in Tunisa, Nadhir is a social entrepreneur, innovator and Artificial Intelligence enthusiast with an ICT background and more than 20 years in information systems mainly in higher education. He has founded and led two start ups in edtech in Tunisia. His first start up, e-Taalim, a free Weblog on e-Learning for executives, professionals and students in Africa and the Arab World was welcomed by several international organizations including UNESCO, ICT4ALL Forum, the European Commission, ALECSO and the OECD. In 2010, e-Taalim was chosen by the European association, Medventures as the best ICT start up in Tunisia. His second start up, ISLAMeBooks, a digital publishing house/ebookstore specialized in Islamic books in many languages was chosen by the World summit award as one of the best 40 eLearning projects worldwide in 2013. He is currently mentoring and coaching start up founders and giving advice in eLearning, ePublishing, eMarketing and eBusiness. In addition, he is also one of 371 Swedish Institute scholars enabling him to pursue a masters in Computer Science for sustainable development in Sweden. His connection to the Nordic region began in 2019 when his eHealth start-up project was among 75 projects from across the globe selected to incubate and launch in the Startup Visa program in Denmark. Tune in and find out more about Nadhir's other areas of interest and knowledge such as sustainability, sustaintech, circular economy, transformative technology, phytotherapy and more. Where to find Nadhir? On LinkedIn [https://www.linkedin.com/in/nadhirdouma/] On Twitter [https://twitter.com/nadhirus] Other topics of interest: About Sousse [https://en.wikipedia.org/wiki/Sousse] Tunisia's Startup Act [https://www.insme.org/the-tunisian-startup-act/] Benefits of Prickly Pear [https://www.mayoclinic.org/healthy-lifestyle/consumer-health/expert-answers/prickly-pear-cactus/faq-20057771#:~:text=Prickly%20pear%20cactus%20%E2%80%94%20or%20also,antiviral%20and%20anti%2Dinflammatory%20properties] Benefits of Rosemary [https://www.medicalnewstoday.com/articles/266370#_noHeaderPrefixedContent] Special Guest: Nadihir Douma.

Todd interviews Dr. Melodie Cook - Professor of English at University of Niigata Prefecture. Contacts:  todd@elllo.org, cookmelo@unii.ac.jp

Rebuilding Products, Increasing Productivity, Remote Culture - Today we are talking to Trey Connell, the CTO at ePublishing, and we discuss what it looks like rebuilding your product from the ground up, using Journaling as a tool for productivity, and how to recognize rockstar employees in a remote working environment. All of this, right here, right now on the Modern CTO Podcast!

Meet our guest:Vegan Culinary Memoirs provides plant-based foods education programming and ePublishing services for education, the food industry, and community groups. https://www.facebook.com/Vegan-Culinary-Memoirs-106296144469028/ https://twitter.com/veganculinarym1 https://www.instagram.com/veganculinarymemoirs/ https://www.linkedin.com/in/lizgarysandiegoca/ Website: www.veganculinarymemoirs.com Subscribe to Pivot! A Vegan Business Interview Series on Soundwise

I think Gareth may actually be the new definition of Hubris for the upcoming decade. http://gmskarka.com/consulting/ Voicemail # ‪(347) 509-5168‬ Support The Tavern www.amazon.com/shop/eriktenkar (affiliate link) https://ko-fi.com/tenkar https://www.patreon.com/tenkarstavern tenkarstavern.com --- Send in a voice message: https://anchor.fm/tavernchat/message Support this podcast: https://anchor.fm/tavernchat/support

Jacob joins the panelists to talk about team collaboration based on his RubyConf 2017 talk, Code Reviews: Honesty, Kindness, Inspiration: Pick Three. Jacob Stoebel is a software developer living in Berea, KY. He spends his days writing web applications in Ruby, JavaScript, and Python, working with data, and leveling up as a software engineer. He works and studies at Berea College. You can find out more about Jacob at jstoebel.com. Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT: CHARLES: Hello and welcome to The Frontside Podcast, the place where we talk about user interfaces and everything that you need to know to build it right. My name is Charles Lowell, a developer at the Frontside. With me today from Frontside also, is Taras Mankovski. TARAS: Hello, hello. CHARLES: Hello, Taras and today, we're going to be talking like we do every time about a piece of the platform that you used to develop user interfaces frontside at your company or organization or wherever it is that you build software. Today we're going to be talking about a piece of the platform that's very, very critical that often gets short shrift or is excluded entirely from what people think of when they think about their tech stack and that's how we as teams collaborate to build and maintain and produce the quality software that we can. With us today is Jacob Stoebel. Welcome, Jacob. JACOB: Hello. CHARLES: Now, what is it that you do, in your day-to-day? JACOB: I'm a full-stack developer for a little company called ePublishing and I mostly work in Rails and React. CHARLES: Rails and React and so, when we were searching for people to talk about how we collaborate these teams, Mandy suggested you because of a talk that you've given at a RubyConf, specifically about code reviews, which I think are actually a huge piece of the collaboration process because it's a major forum where team members get to interact with each other and it's the gateway for making sure code quality is maintained but more than that, I think it's a learning -- a place where we learn. I learned so much both as a reviewer and as someone who is submitting my work and so, it's actually a very important part of the software development process. You have a lot of great examples of how to not do code reviews. JACOB: Yeah, I think I may have been a little bit too indulgent in that talk. I had a lot of fun. I did some research from other people, mainly from anecdotes. I had research from talking to people about really, all the anti-patterns that come out of code reviews. It seems like every few weeks, I'll see a tweet that says something along the lines about how code reviews are broken. I don't really know about that and I have to say, I think I'm kind of lucky at my job that I think they're done in a way that really leaves me feeling pretty positive and that's certainly a good thing but I think what it comes down to -- I'm going to sort of talk about where these ideas come from in a minute -- is that we often have code reviews that for one -- and you can tell me how this is for you too -- often the code review is happening at a point so late in the process, where the feedback that you get may not be actionable. Have you experienced that? JACOB: Before I answer that question, just to kind of echo the sentiment and maybe I'm being presumptuous, I feel like the code reviews that we do are actually very positive, so I haven't got to experience firsthand. Although I have seen conversations on GitHub where it looks kind of like a Celebrity Chef, where you have someone doing the code reviews like Gordon Ramsay up there just screaming and someone has put this plate of food in front of them and kind of picking it apart. That one is extreme but this is actually something that I struggle with, what you were talking about, what is the appropriate point at which to get feedback. I agree that you want to get feedback as soon as possible and sometimes, when you've invested weeks and weeks into something or you're like at Mile 100 and they're like, "You know, at Mile 2, you were supposed to turn right," and now, you're off in the forest and you've been tracking 98 miles in the wrong direction. JACOB: Yeah and the work is due, right? This needs to get ships tomorrow. CHARLES: Right, so you've got massive pressure. This is something that I struggle with myself is when is an appropriate time to really try and be public about what it is that you're doing. JACOB: Yeah. I think that is a really good question and I think what you're getting at and I would agree is that, the sooner, the better and when you can tighten the intervals between feedback is probably better. I'll just take a step back and I'm going to take a longer route to go and get to my point. I am a career changer and before I was in this career, I was a high school theater teacher, so it was really different and I won't give answer why I changed other than this is the greatest [inaudible]. But one thing that I really struggled with is I was working with teenagers and I really wanted to see them grow and improve but at the same time, these were kids and they have fragile egos and I don't want to tear them down, so I came across this really interesting framework for feedback. It is called the Liz Lerman's Critical Response Process and I give credit to her in the talk. This comes out of the dance world. Liz Lerman is a pretty accomplished dancer and choreographer and what she found is that in the dance world and I think it's not too dissimilar from our industry is that the feedback received was often given in a way that was leaving people feel really torn down and mostly, not feeling inspired to go back to their work and make it better. It really felt like feedback is about giving you a grade. It's like, "I'm going to tell you how good of a job you do," and there's certainly a time and place for that but the inspiring question -- I guess the rhetorical question -- that she made is, "Shouldn't the big point about feedback be that it makes you so excited about the work you're doing that you just can't wait to go back to your keyboard and keep working on it," and she found or in the case, back to the dance studio, it really sort of structures this framework for how people can give feedback to a creator and that could be a creator of anything. You mentioned cooking. This could be about food as well that sort of set some guardrails for how we can give feedback that is useful, it's inspiring and it's kind. I'm going to really distinguish between kind and nice. Nice would be, here I'm going to say things that are only pleasant about your work but what I mean by kind is feedback that is really taking care of your team and making them feel like they are respected and cared for as human beings so they don't go home every Friday afternoon and cry on their couch and just drag and coming back on a Monday. That's kind of the basic idea of why we need, maybe a kind of a framework for getting feedback. CHARLES: I agree totally. It's almost like you need to conceive of your feedback is not a gate to quality but a gift to embolden somebody. It's like they've just been doing battle with this code, with this problem, they've been grappling with it and it needs someone to wipe their brow and maybe give them a stiff drink, so that they can get back into the ring and be invigorated. JACOB: Yeah. TARAS: What I'm hearing in this conversation so far is it's kind of like a tone or way of communicating to the person receiving the feedback but sometimes, no matter what your tone is, depending on how your team is set up, depending on the context of your actual code review, it can still kind of land in the wrong place? Have you experienced that where the team conditions impact your ability to actually provide feedback? JACOB: I think I know what you mean. I think what you're talking about is this sort of the organizational structures that are set up are sort of lend themselves to certain modes of feedback and discourage others. I will give this example that I've heard from numerous people and I think this is what you're getting at is feedback that's given at the end. Just like I said, feedback that is given the day before, it has to be shared. Or feedback that it's almost like if we work in an environment where sort of like the hair on fire environment where it's like everything was due yesterday, that's not an environment that's going to be conducive to slowing down, taking a step back and saying like, "Let's point out what we think this work is doing? What questions we have about it? Who has opinions about the direction that's being taken on it?" And really zoom out a little bit more. CHARLES: Do you have any concrete examples of how that early stage feedback has taken place at your work? Is it just over Slack? Maybe, the whole people need to step back from the idea that working on one-week iterations or two-week iterations and at the end of the iteration, everything is due and everything will get merged at that point. How do you kind of break up that structure to say, "No, we're going to try and have checkpoints and milestones?" What are deliverables that you can decompose the work into that fit inside the framework, that are inside the big deliverables, which is sensibly, the feature that you're working on? JACOB: I think first of all, it's the way this thing goes about. I don't think this framework works over Slack. I think it has to be immediate, I think it has to be either in personal or on Skype or Hangouts or something. One of the points of this type of feedback is really about checking in with each other as a team and I think what's great about Slack is that it lets you leave a message and walk away and the unfortunate thing about Slack is it's not meant for sort of attaching how people feel about things or what people's reactions were to them. I think you all have to be in the same space, hopefully with your camera on, if possible and really, just sort of checking in with each other as a team. I can point to times with my team that I think that's really worked out. I think you made a good point when it comes to really getting started with a project because there are times where I made the mistake of not trying to get feedback from my team early on when I was going to start a project and as you can imagine, did that really cost me? It's really getting feedback from my team and my supervisor about the direction this is going to want to go and I'll say from experience, I work on legacy codebases and as you can probably imagine, it's easy to paint yourself into a corner and what the thing about legacy code is that you don't know what pitfalls you're working into. You can get started and you can sort of find into the process, there is some reality about this code that you didn't know and it is really getting in the way of your work that had you known about it, it would have saved you a lot of trouble because you could have planned your way around it. Then the fortunate thing is drawing on the wisdom from people who they know about it because they struggled with it already if they've been around longer than I have. I think that's a really good point. This is a good thing to do. As you're getting started and you can be sharing this is my just initial idea of how I'm going to go about this. What my tech stack is or my understanding of the problem space, all of the above and to really sort of check your assumptions and see if they really check out. CHARLES: I want to circle back a little bit to something you'd mentioned before and that is you want to be kind in a code review and I would say, you probably want to be kind anytime you're giving feedback or interacting with your teammates but what's the process that you can go through if you find yourself struggling? How can I deliver this message that I want to deliver and have it come across this kind? What's a process or checklist that I can go so that I don't open my mouth up and say something that I can't take back or that is going to land wrong? JACOB: I'm glad you asked that and I think that this is a great way to introduce the guidelines for the critical response process. There's basically four steps to it and the way it's structured is you have the person who has created the thing. It could be the person or the team that has created the feature. You have other people who are responders to it. They could be people within your team or they could be others in the organization who are invested in your success. They're not here to tear you down or give you a grade. They're here because they want to see the project do well and then, there's going to be someone who is a facilitator. The way it works and I think this is directly addressing your question is there are guardrails that are going to help you not steer into territory that is going to leave someone feeling torn down. The first step to this process is all the responders are going to say statements of meaning about the work and what I mean by that is you're going to make things that stand out to you that are not attached with an opinion. You could say, for example, "This project is using React hooks. That's something I noticed." You're not going to say, "I think that's a good idea or a bad idea," but you're going to say, "This is what I'm noticing," and that is something that can get jotted down because that's going to be fodder for discussion later on like, "Let's talk about this new feature in React," and let's talk about it later. We can talk about if we think that's a good thing or not or what the implications are for that. The next step after that is that the person who has made the work of the team, they get a chance to ask questions of everybody else about what they thought. You've probably noticed that in a lot of pull requests, someone puts their work out there and then, the next thing that happens is everybody starts commenting on the work and saying what they think about it. This flips it. At first, you as the creator, start asking questions or you can say, "This thing over here, I think it's maybe a little wonky or it's a little hacky but I couldn't think of a better way to do it. What do you think? Do you think it's right? Do you think it's a bad idea?" Or this bit over here, "I'm pulling in the third party library. I think maybe, it's worth it but what do you think? Is it not worth it?" CHARLES: I like that because ultimately, the people who have created the thing are the most familiar with the problem space. They've spent a lot of time thinking about it and so, they can actually direct the conversation to the parts of the implementation that really are the most iffy and the most unknown because everybody is going to feel this need to comment but it's the classic case of bikeshedding really, the true experts or the people who've just been spent all this time implementing and so, people will comment up to their greatest point of familiarity with the problem, which could actually be not that great. Can you say like, "Can you really focus your mental energy on this?" I like that a lot. JACOB: Yeah and really, it sets a good tone. The assumption behind all of this is that the creator, like you said knows the work best and really ought to be in the driver seat when it comes to feedback, so it really sets the tone there and say like, "The creator knows what's most important. Let's give them the first opportunity to frame that," and I know plenty of times like if I'm asked to review a PR and I'm not given any kind of prompt or direction, I will probably scroll to the file. Maybe I'll find the file in that PR that I'm actually familiar with or I'll look for some pattern that's something that's like, "I understand what's going on here. I can give feedback," and if it's all that other thing over there, I'm completely confused, I'm going to ignore it. But the creator could illuminate me a little bit, then I would understand a little bit more and then, I'm in a position to comment on that thing that I otherwise wouldn't have understood. That's the second step. The third step is now the responders get a chance to ask their questions but the important thing about that is that there are neutral questions. The assumption here is that the responders need to better understand the context from which this code was written in order to be able to give their opinion. Here's an example coming from the Rails world. I could say, "Tell me your thought process for using Factory Bot," in this example. If anyone doesn't know that is somewhat of a contentious issue in the Rails community, rather than just coming out guns blazing and say like, "I think this was a bad idea." It's like, "Tell me your process because I want to understand the context you came from and then we can together evaluate if coming from that context makes sense or if it doesn't," so neutral question. They have to be neutral questions. By the way and we've probably all heard this before, this is not a neutral question, "What were you thinking when you decided to do blah-blah-blah-blah-blah." Everyone knows what that means. CHARLES: Right. I was going to say, you can be very, very passive-aggressive with questions. JACOB: Yeah, exactly and this is a place where having a facilitator can really help -- facilitator who is not one of the creators. Someone can just say, "Let's back up. Can you rephrase that without the opinion embedded? Can you just say that again?" and with that again, those are some of the guardrails that keep us on track. After the responders have been able to ask their questions how hopefully everyone has a better understanding of the context from which the code was written, then it's time for opinions with consent of the creators. The way it works is the responders can say, "I have an opinion about using React hooks in this codebase. Would you like to hear it?" The responders can say, "Yes, please. Let me know," or they can say, "No, thank you," because the responders, having the best knowledge of the context, might know that that feedback is not useful. Maybe, they have a really good reason for using React hooks or maybe, they know what's coming in the future or maybe, they know if there's no time to fix it now or it's not worth fixing now. They know the tradeoffs best and so again, those are guardrails and it puts the creator in the place of saying, "That's actually not useful feedback right now. Let's just not use it." They can say, "Yes, please tell me," or they can say, "No, thank you. Let's not talk about that." CHARLES: In the context of a pull request, the process you're describing could be played out in any number of media but in the context of a pull request, the creator is the person actually submitting the code, how do you handle the issue of who pushes the merge button if there's still some opinions that haven't been voiced? For example, a creator says, "No, I don't think that's helpful feedback," is the assumption of then the creator can go ahead and just push the merge button? Or is it basically saying, "I don't want to hear your opinion," relatively rare? JACOB: That is a great question. I think I tried to get at this in the talk. Before one thing, I am probably, like most people don't have the option to just say to my manager, "No, I don't want to hear your opinion." I get that. There is a contrast between the pure version of the feedback process and then reality. They have to balance. But teams can sort of work out the way they give feedback. I have example of an anecdote that someone shared with me once, when I was doing research for this talk. There was this sort of agreement with the manager that their manager wouldn't give feedback on Friday afternoon. They just wouldn't. Everyone preferred that. Everyone sort of wanted, say on Friday afternoons, I'm really going to be just focusing on winding down for the week and I don't want to get dumped on a bunch of feedback. The point being, even though you can't just blanket-ignore feedback, you can work out circumstances with your team for the best way that feedback can be given and circumstances under which, it can be politely declined. CHARLES: I see. TARAS: I'm curious about a different part of this because a lot of this is how to give feedback but I'm really curious about the why part. I think many of us take it for granted that good code reviews are very valuable because a lot of teams that I've encountered that are taking on really big challenges but didn't have a code review process and so, one of things I'm kind of curious is for people or for teams that don't have it in place, what kind of symptoms can they observe in their daily operations that would suggest that maybe code review is something that they need to put in place. CHARLES: Taras, you're talking about kind of the places where we've seen where the culture is just push everything to a branch, there's a 1000 commits there, open up a pull request and no description, no name. It's like, "Here's this thing. I'm taking comments for the next three hours and if everything goes well, let just merge." Are you talking about those kind of situations where really a big culture of pull request or just feedback around change is very, very nascent.? TARAS: Yeah, a lot of times, it's the 'ship it' culture, like this is getting in the way of shipping it. CHARLES: So you're saying like how you sell the entire idea? TARAS: Yeah and if someone is listening who is noticing that, a lot of people would know that we're not really doing code reviews but what are the symptoms that they could be observing that could say like really, this is we need to change, like this can't continue. JACOB: Yeah. One thing that occurs to me as if there's all high level of surprise when you read it, when pull requests are read, it's like, "Oh, you went in that direction." I think that could be an indication that maybe, we could have checked in at the halfway point or even sooner because there seems to be differences of perspective on where this is going or where it should end up that's why [inaudible]. TARAS: At what point do you think people would see this? Is this something that would happen kind of way down the road? Like actually, "How did this end up in the codebase?" CHARLES: That's surprising except deferred even further, right? JACOB: Yeah, who wrote this last few. In having that kind of feedback process, let's sort of take a look at where this project has come in the last few months and see if we can sort of learn from what went well and what didn't. CHARLES: This is related to the concept of surprise, if you see a proliferation of many different patterns to accomplish the same thing, that means the communication is not there. People are not learning from each other and not kind of creating their own code culture together. If that's missing and that manifests itself in all kinds of ways, in bugs, in weird development set up that takes me two hours to get this local environment set up and things like that, if you're seeing those things, chances are you need some way to come together in a code review culture is really, really good for that. JACOB: Yeah and I think in the ideal code review culture, everyone that's sort of brought on board is saying, "I am going to share responsibility in this patch, doing what it's supposed to do and not breaking anything or not burning down the world." You mentioned the 'ship it' culture, I could imagine toxic cultures where the person who shipped it, if it broke everything, it's on them to fix it and they have to get woken up or whatever and the idea about feedback is now we're sort of forming a community around what was done, so it's like the person that push the merge button isn't the only person involved. It's like if we have a culture where we say everyone that participated in the PR is collectively sharing the consequences and that will happen eventually and say like, everyone who's on this thread, it's on all of us if something goes wrong to fix it. I think that is certainly something that one would hope you'd see. TARAS: I'm curious, where do you see this kind of observations usually come from because sometimes, I can imagine there, being a developer, coming on the team and they're like, "Why wouldn't I do code reviews?" and they're like, "Well, we have always not done code reviews," but then there could be someone like a product manager or somebody who's like, "Why wouldn't I do code reviews? We should start code reviews." Have you seen ways of introducing these ideas to teams that have worked out well? JACOB: Yeah and I should probably say that, I'm not a manager, I'm certainly not an expert in how this works so I actually don't have a really great example, personally. I can churn example from working in a previous team, where everyone secretly wanted to be more collaborative but didn't know how to do it because if I'm the first person that puts myself out there and no one knows else knows how to collaborate with me, how to reciprocate, then what was the point? For the top 5% of teams that are just really have great energy together, they don't need a framework to do this sort of thing. They're just doing it naturally. I think for everybody else, we need some kind of guidelines to do this because for better or worse, this is the industry that we're in right now. It isn't built around us. We don't know how to function this way and it's no one's fault. It's just sort of that's the way we've all sort of learn to work in this industry and I suspect we're not the only industry like this but we need some kind of guidelines to do it. TARAS: Maybe it's a difficult question to answer. It varies probably from team-to-team. JACOB: Yeah. CHARLES: Yeah and maybe, we can kind of shift the question just a little bit because I have one that sits alongside not quite the same question but I think related and can bridge it and maybe we can find the answer there. We've talked about a little bit and there's definitely more to unpack there, how to give feedback that's kind and honest and I think to... What was the third? JACOB: Inspiring. CHARLES: Inspiring, that's right. What about from the flip side? This is something that actually comes up with us as consultants but I think it's something that other people will encounter in their jobs too, is what do you do when you are the creator and you're trying to present or share and ultimately solicit feedback from a stakeholder, the CEO of your company, one of your clients, one of your customers and you see them engaging in kind of a mode of feedback that's less than constructive. They're nitpicking on things that aren't really important and maybe, this could be completely and totally inadvertent. Their intention could be that they're trying to help you out but it's really not being helping at all and it's kind of like either tearing you down or just not being productive and it makes you feel... What's the word I'm looking for? Just brings an air of contention to the conversation that's not really helpful to producing the best result for everybody involved. How do you, as the creator actually engage with those people in a positive way and kind of help establish the guardrails and be that agent of change when those guardrails don't exist in their minds yet? JACOB: Yeah, how do you do it, right? It's probably rare that there's going to be an environment where someone's going to say, "We're going to do this framework for feedback," and everyone are onboard from Day 1. I think one of the things that you're probably getting at is the frustration that happens when people start giving feedback. You have this perception that they're giving you feedback that's unuseful and they're only giving it because that's the only thing they can think of or -- CHARLES: Exactly. They got to say something, they need to contribute their two cents to the conversation and some people are trying to be helpful and just aren't. Some people are just trying to appear smart. JACOB: Yeah and it's like, "Oh, boy. They're just really off." CHARLES: But you can derail the main narrative that you're trying to establish and get off in the weeds, kind of skirmishing with these people and after that happens, you're like, "Wait, no. I don't want to end up over there. I was trying to tell a story." JACOB: When I gave this talk once, one idea that someone threw out was when you make a PR, mark up your own code first with everything that you want to draw people's attention to. I think you were getting at this as like, "One frustrating thing is when people getting feedback seem to have less invested than you do." They sort of just flying by and dumping on you and they probably, actually couldn't care less and that can be frustrating. When you're engaging with people that maybe don't know how to get deeply involved in it yet or maybe don't have the time to, you can sort of gently nudge them to sort of like, "I want to talk about this part of it." It's almost like you're giving the answers to the test, which was like, "If you want to be part of the smart conversation, comment over here," and I think from the responders perspective, just speaking personally, I would appreciate that. It gives me an opportunity to feel like I'm actually being useful. We can all probably point to times where all the code review we have to do feels like homework that isn't the best use for our time. It's like, maybe the responder can make us feel like our opinions matter and they will be put to good use when you tell them, "If you comment here, it will probably be put to good use." I think the sort of the way to get started is the responder can just say, "I would really like feedback over here," and I can't speak for everybody but I would suspect that more people than you think would be more than happy to be gently guided in what feedback they should get. CHARLES: Right. I'm thinking how you would do this, for example in the context of a demo that you're giving to stakeholders because there's maybe the inkling of the idea to do that but it's often presented as an apology like, "This screen doesn't work," or, "Your handling isn't quite right. Sorry we're going to fix that." Look at the stuff that's over here and maybe, the way to frame that is a really hard problem based on the legacy architecture that we have for displaying errors and I'm not quite sure how to do it in a robust way and I could really use some feedback there. It's an area of exploration or something that we really need to focus on. You put that out there as I'm demoing this main functionality right now. JACOB: Yes. You sort of say like, "Here's something to watch out for and please, let us know what you think," and then after you could say like, "As a team, we thought up these three possible solutions but we didn't want to move on them because we wanted to get your feedback first, so please impart on us what is the right way to do it." You know, flattery goes a long way. TARAS: I have this imagery coming up in my mind as I'm hearing you guys talk about this that I keep seeing this kind of difference between a line and a triangle, where a line is kind of a tug and pull between, "Did I do this right? No, I didn't do this right." I think those are kind of a bad code review because it's very personal. It's not really where you kind of want to go and then the other way is like a triangle where the end goal that you're trying to get to is somewhere that is beyond both places where you let two people: the recipient of the code review and the giver of the feedback, the end goal that you want to get to is actually someplace else. When we deliver the code and we say, "My code is done," then it invites this kind of linear feedback where it's like, "No, you didn't do it right," but in the other way, "This is where I got to so far. Tell me where you think we could take it next. If you don't think we need to change anything, then we're done. We can merge this." JACOB: Yes. The very intelligent Jessica Kerr said recently on another podcast, there's no such thing as done but you can always make it better. I think you're getting at that point. That's a great question, by the way to ask of your responders -- where should we go next? Where do you see this going next? What will make it better? What would make it more robust? What would make us happier six months down the line when we're looking back on this? But I think of it as the firing range. That's the analogy I gave where it was like, "You put a pull request out and you assert that it is done and if no one can find fault with it, then it's done," and I just don't think that that makes sense. I don't think, really most people actually want to work that way. It's maybe not necessarily even healthy but I think everyone can find, at least I hope, a process that invites them to come into the process and share the way they see things. It can hopefully be enriching and just make everyone feel better along the way. TARAS: This sounds to me like the inspiration part of this conversation because one thing I really like about working at Frontside, I'm an to experienced developer but I know that Frontside is dedicated to doing something much greater than I can do as an individual. When I ask, "What do you think about this?" then I know the feedback is going to be because there something always that is just beyond the reach that could be a little bit better than what we have right now and it's not until I can actually get the feedback from Charles, from Jeffrey and hear, "What do you guys think? Is this it?" and they're like, "What about this?" and I know that the next step is going to be a little bit or maybe even a lot better than what I have right now. I think that's the part that inspires me. I know I have actually gone a little bit further beyond my personal ability to get us to that vision of like this being much better than we could do as individuals. JACOB: Yes and as opposed, "Oh, I screw it up and now, I have to fix it." The framework of find all the errors that I made, even though there may be errors. Let's be honest, there could be things that would be really bad, that would be a security problem but for a growth mindset, to think about it, it's like, "This is a way to make it better." CHARLES: One of the things that you can do to help that is try and find inside every change, try and see the potential that hasn't yet been realized but is enabled by this change, like what exciting paths does this change unlock in your mind, right? And then you can share that. That's a great way to 'inspiration is infectious,' so if you can find inspiration to change, then you might be able to share that with the creators. If something is very personally exciting to you when you see something, maybe spend a little time searching for what you find to be exciting about it. JACOB: Yeah, nice. That's great. CHARLES: Yeah, we might have touched on that. I just bring that up because so often, I'll see the changes that people on my team are submitting and sometimes, it can feel like a cloud burst of like, "We could do this or we could do this or we could do this," and it's great to get excited. JACOB: Yeah. I can share -- recently, there was an example. My coworker opened a pull request and it unlocked something for me where I said like, "You know what? This is making me think about this other thing that I've always hated doing with our legacy codebase. We should do that thing you're doing more because boy, would it make life easier?" and I wonder if it would be worth the time in refactoring X, Y, Z because then I would never ask you A, B, C again and I would be so much happier. TARAS: It makes me think that we need to revisit our pull request template like what would that like? What would be the sections on a pull request template that would facilitate this kind of way? CHARLES: I don't know. I know we're almost a time but before we even get into that, this is a question I have because we talk about pull requests templates, how do you match the amount of process with the scope of the change? Because it's probably a little bit heavy weight if I want to fix a typo and say, "Now we're going to have the creators lay out their case that they're going to ask questions of the reviewers and then the reviewers are going to ask questions and once everybody's been able to write down things that they observe the questions that they have, completely and totally divorced from opinion, now we can talk about opinion that is welcomed." If you're capitalizing one letter, that's probably a little bit heavy weight but on the flip side, it's probably absolutely warranted if it's a major feature that's going to be affecting a huge portions of your revenue stream and so, this is one of the problems I have with pull requests templates is they are one-size, fits-all. Sometimes, a pull request template feels like it's supporting you and sometimes, it feels like the epitome of busy work and I have to spend all this time deleting the sections for the pull requests template. I wish there were ways you could choose different pull requests templates. Maybe, there are. JACOB: So do I. CHARLES: That's a little bit of a quibble that I have is the amount of ritual and ceremony that you have to go through is fixed with a pull request template but it seems like you want to match the amount of process to the scope of the change. JACOB: Yeah, you do and the flipside is also joy. You don't want to give someone too little homework when you really needed the same work. Maybe there's a way to say, when a pull request is opened, the person who opened it or the manager or maybe someone else, has the option to sort of tag the pull request as saying, "This is going to be a bigger conversation. We cannot merge it until we have a face-to-face conversation first with these various stakeholders." Maybe, one of the questions, the first form that everyone gets for every PR gets is what level of PR is this? Is this a quick change? And what people that you just need some quick feedback on? Or is this the long form that you need where there needs to be a sit down with these people? TARAS: Actually, I was thinking what's the adjustment that could be made for pull request is to say, "Here's what a complete pull request looks like. You can opt into whatever section you want," so you decide based on your pull request, what the actual sections of this template are appropriate but then someone can, on the flip side say, "Look, I would really like to learn about the motivations of this pull request. Can you add motivation section?" and understand that from your pull requests. JACOB: Absolutely. You filled out Section A, please answer Section B and C. Yeah, cool. TARAS: Yeah. Because I think what part of the challenge is that we have people look to us, especially people who have a lot of experience, or developers look to us to know what is the right thing to do sometimes or often and I think it's helpful to be a little bit more gentle and saying, "You can decide what is the right amount of detail to set the right conditions for this code review but I will give you some directions for what are things you can consider in including. JACOB: Absolutely. CHARLES: All right. We're a little bit over time, so we should probably go ahead and wrap it up. You are absolutely right, Jacob. This is a topic that keeps on giving. We didn't really move much beyond the pull request and feedback and stuff but we moved a lot around within that topic because it's a big one. Jacob, is there anything that we should mention? Any upcoming talks, meetups? JACOB: No, I have a one-year old and it's all about work and family in this part of the life, so I have nothing to speak of at this point. You can come find me on Twitter as JStoebel. CHARLES: Okay, awesome. Well, thank you so much, Jacob for coming and talking to us. This is a very rich topic. We only really scratched the surface. That's it for our episode today and we'll see you next time. Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at Contact@Frontside.io Thanks and see you next time.

Today we are talking to Trey Connell, the CTO of ePublishing. And we discuss chasing a business model rather than chasing the money, overcoming failure, and creating a remote culture where everyone feels part of the family. All of this, right here, right now, on the Modern CTO Podcast

Panel: Charles Max Wood Dave Kimura Eric Berry David Richards Special Guests: Jacob Stoebel In this episode of Ruby Rogues, the panel discusses code reviews with Jacob Stoebel. Jacob is a Rails and JavaScript developer and works for ePublishing where he does mostly front-end programming. He talks about how he believes that code reviews can be both honest and nice, and that they should inspire the programmer to want to go back and make his/her code better, not tear him/her down. He also gives fours steps to the response process for giving positive and helpful code reviews. In particular, we dive pretty deep on: Jacob intro Rails and JavaScript Are there other places beside code reviews that we give this kind of feedback? Talking about code reviews is a great ice-breaker at conferences Developing is a creative profession Trust must be present for creativity to flow What led you to this topic? Used to be a high school drama teacher It’s possible to give honest and positive feedback Code reviews CAN be honest and nice Code reviews should be inspiring Code review role play Example if a good code review vs a bad code review Four steps to response process Put the author in the driver’s seat as first The opinion has to be consented Keep the conversation civil and collaborative Rule out passive aggressive comments in the future And much, much more! Links: React Dev Summit JS Dev Summit ePublishing Rails JavaScript @JStoebel Jacob’s GitHub Jacob’s Website Picks: Charles 12 Rules for Life by Jordan Peterson The Whole Brain Child by Daniel Siegal Dave Humane Development DEWALT 18-Gauge Pneumatic Brad Nailer Eric Phoenix Framework on Elixir David Thought as a System by David Bohm Radical Candor by Kim Scott Jacob Liz Lerman's Critical Response Process: A method for getting useful feedback on anything you make, from dance to dessert Growing Old by Chad Fowler talk

Panel: Charles Max Wood Dave Kimura Eric Berry David Richards Special Guests: Jacob Stoebel In this episode of Ruby Rogues, the panel discusses code reviews with Jacob Stoebel. Jacob is a Rails and JavaScript developer and works for ePublishing where he does mostly front-end programming. He talks about how he believes that code reviews can be both honest and nice, and that they should inspire the programmer to want to go back and make his/her code better, not tear him/her down. He also gives fours steps to the response process for giving positive and helpful code reviews. In particular, we dive pretty deep on: Jacob intro Rails and JavaScript Are there other places beside code reviews that we give this kind of feedback? Talking about code reviews is a great ice-breaker at conferences Developing is a creative profession Trust must be present for creativity to flow What led you to this topic? Used to be a high school drama teacher It’s possible to give honest and positive feedback Code reviews CAN be honest and nice Code reviews should be inspiring Code review role play Example if a good code review vs a bad code review Four steps to response process Put the author in the driver’s seat as first The opinion has to be consented Keep the conversation civil and collaborative Rule out passive aggressive comments in the future And much, much more! Links: React Dev Summit JS Dev Summit ePublishing Rails JavaScript @JStoebel Jacob’s GitHub Jacob’s Website Picks: Charles 12 Rules for Life by Jordan Peterson The Whole Brain Child by Daniel Siegal Dave Humane Development DEWALT 18-Gauge Pneumatic Brad Nailer Eric Phoenix Framework on Elixir David Thought as a System by David Bohm Radical Candor by Kim Scott Jacob Liz Lerman's Critical Response Process: A method for getting useful feedback on anything you make, from dance to dessert Growing Old by Chad Fowler talk

Panel: Charles Max Wood Dave Kimura Eric Berry David Richards Special Guests: Jacob Stoebel In this episode of Ruby Rogues, the panel discusses code reviews with Jacob Stoebel. Jacob is a Rails and JavaScript developer and works for ePublishing where he does mostly front-end programming. He talks about how he believes that code reviews can be both honest and nice, and that they should inspire the programmer to want to go back and make his/her code better, not tear him/her down. He also gives fours steps to the response process for giving positive and helpful code reviews. In particular, we dive pretty deep on: Jacob intro Rails and JavaScript Are there other places beside code reviews that we give this kind of feedback? Talking about code reviews is a great ice-breaker at conferences Developing is a creative profession Trust must be present for creativity to flow What led you to this topic? Used to be a high school drama teacher It’s possible to give honest and positive feedback Code reviews CAN be honest and nice Code reviews should be inspiring Code review role play Example if a good code review vs a bad code review Four steps to response process Put the author in the driver’s seat as first The opinion has to be consented Keep the conversation civil and collaborative Rule out passive aggressive comments in the future And much, much more! Links: React Dev Summit JS Dev Summit ePublishing Rails JavaScript @JStoebel Jacob’s GitHub Jacob’s Website Picks: Charles 12 Rules for Life by Jordan Peterson The Whole Brain Child by Daniel Siegal Dave Humane Development DEWALT 18-Gauge Pneumatic Brad Nailer Eric Phoenix Framework on Elixir David Thought as a System by David Bohm Radical Candor by Kim Scott Jacob Liz Lerman's Critical Response Process: A method for getting useful feedback on anything you make, from dance to dessert Growing Old by Chad Fowler talk

On the latest episode of TheMediaBriefing, Bauer's head of ePublishing Jim Foster takes us through the publisher's app and distributed publishing strategies and provides a look back at how the company went from having no apps to considering one for each publication. Chris and Esther try not to sound too incredulous when he describes a time in magazine publishing when the market could support multiple magazines about carp.

Wrote a book? ePublishing? Self publishing? On The Mind Your Own Business Show today we discover what you need to succeed when promoting your book in the digital world.

## PDF Yes. But pdf and epub modules are the second generation. Fileviewer module was the first generation. It uses Poppler, the popular pdf lib in Linux, to convert pdf file into png images and display them in browser.  After several years, the Mozilla Foundation created pdf.js which allow browsers use HTML5 and JavaScript to display PDF file. Today pdf.js has become the default PDF plugin in Firefox. I wrote PDF module to integrate it into Drupal.    * So, this just integrates pdf.js into Drupal? * Can you create pdfs with the module?   ## ePub Since Amazon launched Kindle, ebook market was getting hot. Google and Apple joined the battle soon. Epub format as an open standard chosen by many new competitors in this market became popular. Thanks to Jake Hartnell the author of epub.js, an open source Javascript epub lib, we can display epub file in the browser as well. So I wrote epub module to integrate it into Drupal.  Google Book Search has been renamed into Google Books and become a part of Play Books. Both Google and Amazon have HTML5 online reader now. Although epub.js is not as good as them, it has gotten most features for a online ebook reader.    * Do either of these provide search functionality? ##Apachesolr_file * How does Apachesolr_file fit into this? It’s always easy to use Ctrl-F to search in one book. If you have thousands of books or even more, you need a full-text search engine to index them all. Apachesolr_file module uses Solr, Apache Foundation’s popular full text search engine, to index files.  We already have apachesolr module and apachesolr_attachments‎ module. The difference between apachesolr_attachments‎ and apachesolr_file is - apachesolr_attachments was designed to index the files with nodes and apachesolr_file was designed to index file entity (the new conception since Drupal 7) for purely file management.  Not only pdf and epub but also other popular file formats like MS Word, Excel, PowerPoint… can be indexed by Solr (https://tika.apache.org/1.5/formats.html all the formats supported by Tika - the file parser used by Solr). So you can also use this module on intranet for companies, schools and other organizations.  ## Application   * Do you know of any sites that are using these now? * What are some other applications you can see for these modules?   ## NodeSquirrel Ad Have you heard of/used NodeSquirrel? Use "StartToGrow" it's a 12-month free upgrade from the Start plan to the Grow plan. So, using it means that the Grow plan will cost $5/month for the first year instead of $10. (10 GB storage on up to 5 sites)

Topic: Publishing Options It's your choice, but how do you make a decision that's right for you? This show explores and explains what each direction to publication, their pitfalls, and their benefits. Biography: Susan Wingate began writing as a child when she learned her father was a writer.   A vibrant public speaker, Susan offers inspiring, motivational talks about faith, the craft of writing, publishing and marketing, and how to survive in this extremely volatile ePublishing industry. She enjoys chatting with folks about her books at writing conferences, libraries and book stores around the country. She also loves to visit with book clubs for more intimate talks. Website:  www.SusanWingate.com

Topic:  Get Published, Stay Published There are five key items you need to maintain a publishing career. This episode will discuss each in detail. About my Guest: Susan Wingate began writing as a child when she learned her father was a writer.   A vibrant public speaker, Susan offers inspiring, motivational talks about faith, the craft of writing, publishing and marketing, and how to survive in this extremely volatile ePublishing industry. She enjoys chatting with folks about her books at writing conferences, libraries and book stores around the country. She also loves to visit with book clubs for more intimate talks. Website: www.susanwingate.com

On The MYOB Show today we discover how to succeed in the world of online self ePublishing. Have you have ever dreamt of becoming a writer? Penning your first novel has never been easier, cheaper and more accessible to do, thanks to the online digital revolution. With help from our expert guest we find out how to create your own eBook, how to market it and we discover what issues you should plan to avoid. Who’s on the show? Guest: Lee Bullen Joining us via Skype is Lee Bullen an author and illustrator who successfully self published the eBook Beset. Lee has been there, done that and succeeded to get to the other of self publishing online. Presenter: Dom O'Neill MA and BA (Hon) Radio and media graduate with an 10 years experience working freelance in the UK broadcast industry. Why listen? Back in the day to get a book published you needed to either a publishing house “picking up” you manuscript, costly self publishing projects or running down the mine field of vanity publishing. Nowadays there’s so many more option for those who us not luck enough to get that lucrative book deal up front. Self publishing is easier and cheaper then ever. However is the ePublishing market the gold mine it appears to be? On the show today we find out how to ePublish, we discover the pitfalls of the business and what you need to think about before you create your 1st eBook. Want to suicceed? Listen to The MYOB Show On-Demand! Want to know more? We have loads of useful and entertaining Podcasts at myobshow.com  

Today, it seems that everybody has a blog. The blog is a way for a common person to put their ideas out for the masses to see and comment upon. E-Publishing Expert, Susan Wingate, can explain how to make your blog the envy of all your friends. Guest:  Susan Wingate, Winner of five literary awards including #1 Amazon Best Selling Author and E-publishing Expert. Meet Susan Wingate Winner of five literary awards including #1 Amazon Best Selling Author. Expert in e-book publishing Diverse author with published work ranging from young adult romance to dark mystery The third book of her award winning “Bobby's Diner” series is being launched soon 2011 Forward National Literature Award for Drama and 2011 International Best Books Award, Finalist for Women's Fiction for “Drowning” 2010 International Best Books Award, Finalist for Women's Fiction and 2009 Next Generation Indie Book Awards, Finalist for Women's Fiction for “Bobby's Diner” 2009 Textnovel Editor's Choice Award & Finalist for “Camouflage” Susan has won various other literary awards for her short stories and poetry

Jim Minz, Lee Martindale, Chris Morris, Janet Morris, Dan Hollifield, Holly McClure and Walt Boyes are today's featured guests. Topic: ePublishing as viewed principally by various publishers and editors who have successfully transitioned into it without abandoning their traditional paper-based publishing business models. Hosted by Stephen Euin Cobb, this is the September 26, 2012 episode of The Future And You. [Running time: 52  minutes] This panel was recorded on July 21, 2012 before a live audience in Chattanooga Tennessee at the science fiction and fantasy convention: LibertyCon. Special thanks go to Derek Spraker and John Trieber of LibertyCon who recorded this and many other panels for me.

Michael Hyatt is a bestselling author, popular blogger and the Chairman of Thomas Nelson Publishers - the largest Christian publishing company in the world. Join us as Mr. Hyatt discusses: his background, what Thomas Nelson does and who they publish, his most popular blog topics, his upcoming book Platform, ePublishing, his #1 tip for ministry workers, and what he will be covering in his keynote address and break-out session at ISC 2012. Right click the link below to download an iPod friendly (.m4v) format.

Michael Hyatt is a bestselling author, popular blogger and the Chairman of Thomas Nelson Publishers - the largest Christian publishing company in the world. Join us as Mr. Hyatt discusses: his background, what Thomas Nelson does and who they publish, his most popular blog topics, his upcoming book Platform, ePublishing, his #1 tip for ministry workers, and what he will be covering in his keynote address and break-out session at ISC 2012. Right click the link below to download an iPod friendly (.m4v) format.

If you like Listener Feedback and interviews you'll LOVE this show. Guy's wife has a bit of an incident but she's OK now (which means Guy is cleared for MacWorld!), Gaz has OCD or does OCD have Gaz? Guy and Gaz prove without a shadow of a doubt that neither have Polyphobia and Tonya Engst from TidBits comes on to talk a bit about Tids and ePublishing

  SHOW NOTES- Host Bridgette Mongeon talks with author John Shore about his books, the publishing industry and e-publishing.  Listening time approximately 32.16 minutes  HOW TO LISTEN OR SUBSCRIBE The Inspirations/Generations podcast and the Creative Christian podcast are recorded three times a month. To listen to the podcast press the purple button. To subscribe to the podcast in iTunes press the Subscribe to this podcast in iTunes button. If you would like to see a list of the podcasts that have been recorded and read about the hosts please visit the host bios web page on the Godsword.net website. These podcasts can also be found and listened to from the God's Word Facebook fans page. A player has been added to this blog on the right column as well as on the main God's Word website. Sponsored by God's Word Collectibles http://www.godsword.net Give God's Word as a gift, collect God's Word in your heart!  

Blogs, podcasts, and other new media outlets have changed the way people get their news. Immediate access to information presents new opportunities as well as challenges for science communication. Watch Carl Zimmer, science writer for the New York Times and host of MicrobeWorld's Meet the Scientist podcast, at the Marian Koshland Science Museum in Washington, D.C., discuss how scientists and journalists are using new media outlets while avoiding their pitfalls. Carl Zimmer is an award-winning author and science journalist. He is the author of seven books, the most recent of which is The Tangled Bank: An Introduction to Evolution. In addition to writing books, Zimmer contributes articles to the New York Times, as well as to magazines including National Geographic, Time, Scientific American, Science, and Popular Science. He also writes an award-winning blog, The Loom. From 1994 to 1998 Zimmer was a senior editor at Discover, where he remains a contributing editor and writes a monthly column about the brain.

Blogs, podcasts, and other new media outlets have changed the way people get their news. Immediate access to information presents new opportunities as well as challenges for science communication. Watch Carl Zimmer, science writer for the New York Times and host of MicrobeWorld's Meet the Scientist podcast, at the Marian Koshland Science Museum in Washington, D.C., discuss how scientists and journalists are using new media outlets while avoiding their pitfalls. Carl Zimmer is an award-winning author and science journalist. He is the author of seven books, the most recent of which is The Tangled Bank: An Introduction to Evolution. In addition to writing books, Zimmer contributes articles to the New York Times, as well as to magazines including National Geographic, Time, Scientific American, Science, and Popular Science. He also writes an award-winning blog, The Loom. From 1994 to 1998 Zimmer was a senior editor at Discover, where he remains a contributing editor and writes a monthly column about the brain.

Blogs, podcasts, and other new media outlets have changed the way people get their news. Immediate access to information presents new opportunities as well as challenges for science communication. Watch Carl Zimmer, science writer for the New York Times and host of MicrobeWorld's Meet the Scientist podcast, at the Marian Koshland Science Museum in Washington, D.C., discuss how scientists and journalists are using new media outlets while avoiding their pitfalls. Carl Zimmer is an award-winning author and science journalist. He is the author of seven books, the most recent of which is The Tangled Bank: An Introduction to Evolution. In addition to writing books, Zimmer contributes articles to the New York Times, as well as to magazines including National Geographic, Time, Scientific American, Science, and Popular Science. He also writes an award-winning blog, The Loom. From 1994 to 1998 Zimmer was a senior editor at Discover, where he remains a contributing editor and writes a monthly column about the brain.  

Blogs, podcasts, and other new media outlets have changed the way people get their news. Immediate access to information presents new opportunities as well as challenges for science communication. Watch Carl Zimmer, science writer for the New York Times and host of MicrobeWorld's Meet the Scientist podcast, at the Marian Koshland Science Museum in Washington, D.C., discuss how scientists and journalists are using new media outlets while avoiding their pitfalls. Carl Zimmer is an award-winning author and science journalist. He is the author of seven books, the most recent of which is The Tangled Bank: An Introduction to Evolution. In addition to writing books, Zimmer contributes articles to the New York Times, as well as to magazines including National Geographic, Time, Scientific American, Science, and Popular Science. He also writes an award-winning blog, The Loom. From 1994 to 1998 Zimmer was a senior editor at Discover, where he remains a contributing editor and writes a monthly column about the brain.  

    Conference Agenda; InDesign CS5 Launch; Quark Features Missing in InDesign; Hot Forum Post; Obscurity of the Week: Best Joins ----- Details below, or go to http://indesignsecrets.com/indesignsecrets-podcast-122.php for Show Notes, links, coupon codes, and to leave a comment! ----- Listen in your browser: InDesignSecrets-122.mp3 (13.8 MB, 27:27 minutes) See our Show Notes for links mentioned in this episode. The transcript of this podcast will be posted soon. InDesignSecretsLive Seminars -- news/updates Sessions announced for the Print and ePublishing Conference InDesign CS5 (and those other minor Suite programs) launch on April 12 QuarkXPress features that aren't in InDesign (and workarounds for some of them) Hot Forum Post: Cool Keyboard Shortcuts Obscure InDesign Feature of the Week: Best Joins News and special offers from our sponsors: >> DTPTools offers a suite of 12 InDesign plug-ins in a single package called BlatnerTools (because our own David Blatner designed it)! It works with CS3 and CS4 on both Mac and Windows. You can see a video of a lot of the cool things BlatnerTools can do, and when you're convinced you just gotta have it, you can get 10% off the normal $149 price by using the discount code IDSBLATNERTOOLS in the DTPTools online store. -- Links mentioned in this podcast: > Members! Watch your e-mail for discount codes to InDesignSecretsLive.com events: InDesign Seminars and the Print and ePublishing conference > Print and ePublishing Conference Agenda is now up! The $200 early bird discount ends on April 9, so register as soon as you can. > CS5 is coming! CS5 is coming! > Page Tools lets you have more than one page size in one ID document > You may be interested in that CoolKerning "kerning table" plug-in we mentioned > Or do it the old-fashioned way by editing the kern pairs in the font itself > Fritz wrote up a workaround for character-level opacity changes > Synchronized text in InDesign solution 1 and solution 2 > David's uplifting post, Things that InDesign Can't Do > Adobe's Feature Request form that they actually read! > Hot Forum Post about Cool Keyboard Shortcut Changes

  Tips for organizing styles; Gabriel Powell interview; ePub info; Obscurity of the Week: Sort Bookmarks ----- Details below, or go to http://indesignsecrets.com/indesignsecrets-podcast-121.php for Show Notes, links, coupon codes, or to leave a comment! -----  Listen in your browser: InDesignSecrets-121.mp3 (15.2 MB, 30:19 minutes) See the Show Notes for links mentioned in this episode. The transcript of this podcast will be posted soon. Best practices for organizing and naming text styles InDesignSecrets Seminars & Conference update; new speakers Mike Rankin's interview with ePub expert Gabriel Powell at the O'Reilly TOC Conference Emerging and evolving open standards discussed at the conference, such as the Open Publication Distribution System (OPDS) for eBooks The new "browser wars" (how different eReaders interpret the same content feed) Obscure InDesign Feature of the Week: Sort Bookmarks Bonus: David recites from memory the first 20 digits of Pi (in honor of Pi day, March 14—aka 3.14!) -- Links mentioned in this podcast: > Members! Watch your e-mail for discount codes to InDesignSecretsLive.com events: InDesign Seminars and the Print and ePublishing conference) > Vancouver InDesign User Group (where David's speaking soon) > O'Reilly's Tools of Change conference > Gabriel Powell's InstantInDesign web site > CreativePro.com reprinted Gabriel's ePub articles from InDesign Magazine > Learn about the OPDS > Lexcycle's Stanza application (Note: Lexcycle rhymes with Bicycle) > David's Joy of Pi book