Author Posts

John Arundel is a DevOps consultant. Which means he helps businesses use software better. But when he's not supporting his clients, John is writing for Packt. John has written a number of books over the last few years, most recently Puppet 5 Beginner's Guide. Puppet is one of the most popular tools in the DevOp toolchain; it's a tool that gives administrators and architects significant control over their infrastructure. For that reason, it's a tool worth exploring - whatever field you're working in. It's likely to play a large part in the continued rise of DevOps throughout 2018. We spoke to John about Puppet, DevOps, and his new book - as well as his experience writing it. Packt: Your book is published now. How does it feel to be a published author? John Arundel: Pretty great! At one time I wrote technical manuals for Psion, the palmtop computer manufacturer. Thanks to a conservative house style, the kind of books I wrote said things like: “To access file operations, select the File menu”. Not exactly a page-turner. I’m very happy now to be able to publish a book which is written more or less exactly the way I want it, on a subject I find very interesting, and including a lot of jokes. What benefits did writing a book bring to your specialist area? JA: The funny thing is that despite being a Puppet user almost since the very beginning, I really don’t use many of its features. In fact, most of them have been added since I started using Puppet, and I don’t have a lot of time to experiment with new stuff, so writing the book was a great opportunity to delve into all the Puppet features I didn’t know about. I’m hoping that readers will also find out stuff they didn’t know and that will come in useful. If just one person is helped and inspired by this book... then I’m not giving refunds to the others. It’s done a lot to raise the profile of my consulting business; I was introduced to one potential client as “This is John. He literally wrote the book on Puppet”. I had to modestly point out that in fact, other, probably better books are available. Our authors usually have full-time jobs whilst writing for us. Was this the case for you and how did you approach managing your time? JA: As any freelancer knows, the job is more than full-time. I practically had to invent new physics to figure out a way of using my negative free time to write a book. I blocked out one day a week devoted to writing, and set myself a goal of a number of hours to achieve each month, which I mostly met. Because the book is so code-focused, I had to not only write about each technique I was describing, but also develop complete, working, reusable software in Puppet to implement it, and then test this on a virtual machine. Quite frequently I’d discover later that I’d been doing something wrong, or a behaviour in Puppet changed, and I’d have to go back and fix all the code. I’m sure there are still quite a few bugs, which I am going to pretend I’ve deliberately inserted to help the reader learn to debug and fix Puppet code: something they will, after all, spend a great deal of time doing. In all, what with researching, writing, coding, testing, fixing, editing, and complaining on Twitter, I spent about 200 hours on the book over 8 months. While writing your book, did you find that it overshadowed personal life in any way? How did you deal with this? JA: Not really. It could have, if I’d got into serious deadline trouble. Fortunately, I managed to keep up a continuous, manageable level of mild deadline trouble. I don’t think my friends or family noticed, except occasionally I’d say things at dinner like, “Could you pass the Puppet? I mean pepper.” Do you have any advice for other authors who may be interested in writing for Packt, but are still unsure? JA: Go for it! But make sure you have two hundred unallocated hours in your schedule. You’d be amazed how much time you can save by not watching TV, going out, putting on clothes, etc. Really, my advice would be to plan the book carefully - agreeing the outline in advance with your editor helps a lot. Henry Ford said that there are no big problems, just lots of little problems. Breaking down a book into chapters and sections and subsections and tackling them one by one makes it seem less daunting. And managing your time well helps avoid last-minute-essay syndrome. Do you have any tips for other authors, or tricks that you learnt whilst writing, that you'd like to share? JA: One good tip is, once you’ve written a chapter, let it lie fallow for a few weeks and then come back to it with a fresh eye. What you thought were immaculately-crafted sentences turn out to be pompous waffle. And what seemed clear and explicit now seems larded with techno-babble. I read somewhere that P.G. Wodehouse would stick each page of manuscript to the wall as he wrote it, somewhere around the skirting board level, and as he obsessively reworked and rewrote and polished the text he would gradually move it higher and higher up the wall until he judged it good enough - somewhere near the ceiling. Well, I’m not saying I’m P.G. Wodehouse — I’ll leave that for others to say — but it’s a useful way to think about the writing process. Rewrite, rewrite, rewrite! “What is written without effort,” Dr Johnson pointed out, “is in general read without pleasure.” Was there anything interesting that happened during the writing of the book? JA: Only in the sense that the Chinese use when they curse you to live in interesting times. Quite often I wrote myself to a standstill and just stared blankly at the laptop, hoping it would explain something complicated for me, or think up a useful and instructive example when I couldn’t. On one occasion I decided that the best thing to do with a certain long, difficult, and laboriously-constructed section was to delete it altogether, improving the book immeasurably as a result. The deleted scenes will be available on a forthcoming DVD, together with a ‘making of’ documentary which consists of me frowning at a screen for 200 hours and intermittently making tea. How did Packt’s Acquisition Editors help you - what kind of things did they help you with and how did they support you throughout the writing process? JA: The biggest help at the start was giving me structure by insisting on an outline, and then setting individual chapter deadlines to plan the writing time - then gently but persistently enforcing them. What was also very useful was to see sample chapters of other books, to get an idea of where I was supposed to be going, and getting very detailed feedback on the early chapters about exactly how to lay things out and how to make everything consistent. Beyond that, I was pleased and surprised by how little the editors interfered with what I was doing. By and large I was allowed to write my own book the way I wanted. No one suggested I write sentences like “To access file operations, select the File menu.” When I asked for help, I got it, and when I didn’t, I was left in peace and trusted to do the right thing. That’s a great way to write. What projects, if any, are you working on at the moment? Several people have asked what the next book’s going to be. I have said, only half-jokingly, that I might do one on Chef. I have a kind of a semi-formed idea about a book of system administration patterns and practices, based on my several decades worth of experience (read: mistakes). But just now I’m enjoying a break from writing, and I’m spending my negative free time reading other people’s books, playing Beethoven on my toy piano like Schroeder out of Peanuts, and learning to bake the perfect Cornish pasty. Ah! Excuse me, that was the oven timer. Thanks for taking the time to talk to us, John! You can find John's latest book, Puppet 5 Beginner's Guide, here.

What initially drew you to write your book for Packt Publishing? In 2009, I started writing technical articles on my personal blog. I would write about my field, Geographic Information Systems, or any other technical articles. Whenever a new technology emerged, a new product,or sometimes even mere tips or tricks,I would write an article about it. My blog became a well-known site in GIS, and that is when Packt approached me with a proposed title. I always wanted to write a book but I never expected that the opportunity would knock on my door. I thank Packt for giving me that opportunity. When you began writing, what were your main aims? My main aim was to write a book that readers in my domain could grab and benefit from. While working on a chapter, I would always imagine a reader picking up the book and reading that particular chapter and asked myself, what could I do better? And then I tried to make the chapter as simple as possible and leave nothing unexplained. What did you enjoy most and what was most rewarding about the experience of writing? Think about all the knowledge, information, ideas, and tips that you possess. You knew you had it in you somewhere but you didn’t know the joy and delight you would feel when this knowledge slipped through your fingertips into a physical medium. With each reading I would reread and polish the chapters;it seems there is always room for improvement in writing. Why, in your opinion, is ArcGIS exciting to discover, read, and write about? ArcGIS is not a new technology; it has been around for more than 14 years. It has become mature and polished during these years. It has expanded and started touching other bleeding-edge technologies like mobile, web, and the cloud. Everyday this technology is increasingly worth discovering and everyday it benefits areas like health, utilities, transportation, and so on. Why do you think interest in GIS is on the rise? If you read The Tipping Point,by Malcolm T. Gladwell, you will understand that the smartphone was actually a tipping point for the GIS technology. GIS was only used by enterprises and big companies who wanted to add the location dimension to their tabular data so it helped them better visualize and analyze their information. With smartphones and GPS, geographic location became more relevant. Pictures taken with smartphones are tagged with location information. Applications were developed to harness the power of GIS for routing, finding the best restaurants in an area, calculating shortest routes, finding information based on geo-fencing technology that sends you text messages when you pass by a shop, and so on. The popularity of GIS is rising and so is the interest in adapting this technology. What do you see on the horizon for GIS? High end processing servers are being sent to the cloud while we are carrying smaller and smaller gadgets. Networking is getting stronger every day with the LTE and 4G networks already setup in many countries. Storage has become no issue at all. The Web architecture is dominant so far and it is the most open and compatible platform that has ever existed. As long as we keep using devices, we will need geographic information systems. The data can be consumed and fetched swiftly from anywhere in the world from the smallest device. I believe this will evolve to an extent that everything valuable we own can be tagged with a location, so when we misplace something or lose it, we can always use GIS to locate it. Any tips for new authors? My role model author is Seth Godin; the first book I ever read was his. When I told him about my new book and asked him for any advice he might give me as a new author, he told me and I quote,″Congratulations, Hussein .This is thrilling to hear; my only advice is to keep writing!″ I took his advice and now I′m working on my second book with Packt. Another personal tip I can give to new authors is thatwriting needs focus, and I find music the best soul feeding source. While working on my first book,I discovered this site www.stereomood.com, which plays music that will help you write. Another thing is to use a clutter free word processor application that will blank the entire screen so you are only left with your words. I use WriteMonkey for Windows and Focus writer for Mac.

School of Code is a company on a mission to help more people benefit from technology. It has created an online multiplayer platform that aims to make coding fun, simple and accessible to all. This platform has been used by over 120,000 people since its launch in December 2016, and School of Code recently won the ‘Transforming Lives’ award at the 2017 Education Awards. The company was founded by Chris Meah while he was completing his PhD in Computer Science at the University of Birmingham.  As headline sponsors, Packt founder and CEO Dave Maclean shares his thoughts on the programme. “The number and diversity of the applicants proves how many people in Birmingham are looking to learn key skills like HTML, CSS, Javascript and Node.JS. Packt is excited to sponsor School of Code’s Bootcamp participants to increase the population of skilled developers in the West Midlands, which will have an impact on the growth of innovative start-ups in this region.” We spoke to Sharon Kaur, who's been involved with a School of Code bootcamp about her experience and for her perspective on tech in 2018. Packt: Hi Sharon! Tell us a little about yourself. Sharon Kaur: My name is Sharon. I am a choreographer and dancer for international music groups. I am also an engineering and technology advocate and STEM Ambassador for the UK and India – my main aim is getting more young girls and ethnic minorities interested in and pursuing a career in science, technology and engineering. What were you doing before you enrolled for School of Code and what made you want to sign up? I previously studied my BEng honours and MSc degrees at University of Surrey, in general and medical engineering. I worked in the STEM education industry for a few years and then gained my teaching qualification in secondary school/sixth form Science in Birmingham. I recently started learning more about the technology industry after completing an online distance-learning course in cyber security. I was on Facebook one day in June and I saw an advert for the first ever School of Code Bootcamp, and I just decided to dive in and go for it! Do you think there is a diversity issue in the tech sector? Has it affected you in any way? I definitely think there is a major problem in the technology industry, in terms of diversity. There are far too many leadership and management positions taken up by upper/middle class, white men. There needs to be more outreach work done to attract more women and ethnic minority people into this sector, as well as continuing to work with them afterwards, to prevent them from leaving tech in the middle of their careers! This has not affected me in any direct way, but as a female from an engineering background, which is also a very male-dominated sector, I have experienced some gender discrimination and credit for work I produced being given to someone else. Why do you think making technology accessible to all is important? Technology opens up so many doors to some really exciting and life-fulfilling work. It really is the future of this planet, and in order to keep improving the progress of the global economy and human society, we need more and more advanced technology and methods, daily. This means that there is a dire need for a large number of highly competent employees working continuously in the tech sector. What do you think the future looks like for people working in the tech industry? Will larger companies strive to diversify their workforce, and, why should they? In my opinion, the future looks extremely exciting and progressive! Technology will only become more and more futuristic, and we could be looking at getting more into the sci-fi age, come the next few centuries, give or take. So, the people who will work in the tech sector will be highly sought after – lucky them! I would hope though, that large corporations will change their employee recruitment policies, in terms of a more diverse intake, if they truly want to reach the top of their games, with maximum efficiency and employee wellbeing. School of Code encourages the honing of soft skills through networking, team work and project management. Do you think these skills are vital for the future of the tech industry and attracting a new generation, shaking off the stereotype that all coders are solitary beings? Why? Yes, definitely – soft skills are just as important, if not slightly more, than the technical aptitude of an employee in the tech industry! With collaboration and a business acumen, we can bring the world of technology together and use it to make a better life for every human being on this planet. The technology industry needs to show its solidarity, not its divisiveness, in attracting the next generation of young techies, if it wants to maintain its global outreach. What advice would you give to someone who wanted to get into the tech sector but may be put off by the common preconception that it is made up of male white privilege? I would say go for it, dive in at the deep end and come out the other side the better person in the room! Have the courage to stand up for your beliefs and dreams, and don't ever let anyone tell you or make you feel like you don't deserve to be standing there with everyone else in the room – pick your battles wisely, become more industry – and people-savvy, choose your opportune moment to shine, and you'll see all the other techies begging you to work with them, not even for them! Find out more about School of Code.  Download some of the books the Bootcampers found useful during the course: Thinking in HTML Thinking in CSS Thinking in JS series  MEAN Web Development React and React Native Responsive Web Design

An unreliable versioning tool makes product development a herculean task. Creating and enforcing checks and controls for the introduction, scrutiny, approval, merging, and reversal of changes in your source code, are some effective methods to ensure a secure development environment. Git and GitHub offer constructs that enable teams to conduct version control and collaborative development in an effective manner.  When properly utilized, Git and GitHub promote agility and collaboration across a team, and in doing so, enable teams to focus and deliver on their mandates and goals. We recently interviewed Joseph Muli and Alex Magana, the authors of Introduction to Git and GitHub course. They discussed the various benefits of Git and GitHub while sharing some best practices and myths. Author Bio Joseph Muli loves programming, writing, teaching, gaming, and travelling. Currently, he works as a software engineer at Andela and Fathom, and specializes in DevOps and Site Reliability. Previously, he worked as a software engineer and technical mentor at Moringa School. You can follow him on LinkedIn and Twitter. Alex Magana loves programming, music, adventure, writing, reading, architecture, and is a gastronome at heart. Currently, he works as a software engineer with BBC News and Andela. Previously, he worked as a software engineer with SuperFluid Labs and Insync Solutions. You can follow him on LinkedIn or GitHub. Key Takeaways Securing your source code with version control is effective only when you do it the right way. Understanding the best practices used in version control can make it easier for you to get the most out of Git and GitHub. GitHub is loaded with an elaborate UI. It’ll immensely help your development process to learn how to navigate the GitHub UI and install the octo tree. GitHub is a powerful tool that is equipped with useful features. Exploring the Feature Branch Workflow and other forking features, such as submodules and rebasing, will enable you to make optimum use of the many features of GitHub. The more elaborate the tools, the more time they can consume if you don’t know your way through them. Master the commands for debugging and maintaining a repository, to speed up your software development process. Keep your code updated with the latest changes using CircleCI or TravisCI, the continuous integration tools from GitHub. The struggle isn’t over unless the code is successfully released to production. With GitHub’s release management features, you can learn to complete hiccup-free software releases. Full Interview Why is Git important? What problem is it solving? Git, like all other version control tools, exists to solve for one problem, change. This has been a recurring issue, especially when coordinating work on teams, both locally and distributed, that specifically being an advantage of Git through hubs such as GitHub, BitBucket and Gitlab. The tool was created by Linus Torvalds in 2005 to aid in development and contribution on the Linux Kernel. However, this doesn’t necessarily limit Git to code any product or project that requires or exhibits characteristics such as having multiple contributors, requiring release management and versioning stands to have an improved workflow through Git. This also puts into perspective that there is no standard, it’s advisable to use what best suits your product(s). What other similar solutions or tools are out there? Why is Git better? As mentioned earlier, other tools do exist to aid in version control. There are a lot of factors to consider when choosing a version control system for your organizations, depending on product needs and workflows. Some organizations have in-house versioning tools because it suits their development. Some organizations, for reasons such as privacy and security or support, may look for an integration with third-party and in-house tools. Git primarily exists to provide for a faster and distributed version system, that is not tied to a central repository, hub or project. It is highly scalable and portable. Other VC tools include Apache SubVersion, Mercurial and Concurrent Versions System (CVS). How can Git help developers? Can you list some specific examples (real or imagined) of how it can solve a problem? A simple way to define Git’s indispensability is enabling fast, persistent and accessible storage. This implies that changes to code throughout a product’s life cycle can be viewed and updated on demand, each with simple and compact commands to enable the process. Developers can track changes from multiple contributors, blame introduced bugs and revert where necessary. Git enables multiple workflows that align to practices such as Agile e.g. feature branch workflows and others including forking workflows for distributed contribution, i.e. to open source projects. What are some best tips for using Git and GitHub? These are some of the best practices you should keep in mind while learning or using Git and GitHub. Document everything Utilize the README.MD and wikis Keep simple and concise naming conventions Adopt naming prefixes Correspond a PR and Branch to a ticket or task. Organize and track tasks using issues. Use atomic commits [box type="shadow" align="" class="" width=""]Editor’s note: To explore these tips further, read the authors’ post ‘7 tips for using Git and GitHub the right way’.[/box] What are the myths surrounding Git and GitHub? Just as every solution or tool has its own positives and negatives, Git is also surrounded by myths one should be aware of. Some of which are: Git is GitHub Backups are equivalent to version control Git is only suitable for teams To effectively use Git, you need to learn every command to work [box type="shadow" align="" class="" width=""]Editor’s note: To explore these tips further, read the authors’ post ‘4 myths about Git and GitHub you should know about’.  [/box] GitHub’s new integration for Jira Software Cloud aims to provide teams a seamless project management experience GitLab raises $100 million, Alphabet backs it to surpass Microsoft’s GitHub GitHub introduces ‘Experiments’, a platform to share live demos of their research projects  

Christoph is the CTO of GESIM, a Swiss start-up company, where he is responsible for their simulation software and web interface built with Angular and D3. He is a passionate, self-taught, software developer and web-enthusiast with more than 7 years’ experience in designing and implementing customer-oriented web-based IT solutions. Curious about new technologies and interested in innovation Christoph immediately started using AngularJS and D3 with the first versions. We caught up with him to get his insights into writing with Packt. Why did you decide to write with Packt, what convinced you? Initially, I wasn’t sure about taking on such a big project. However after doing some research and discussing Packt’s reputation with my University colleagues, I was sure I wanted to go ahead. I was also really passionate about the topic, Angular is one of my favourite tools for frontend JavaScript. As a first-time Packt author, what type of support did you receive to develop your content effectively? I started off working independently, researching papers, developing code for the project and reading other books on similar topics, and I got some great initial feedback from my University colleagues. As the project progressed with Packt, I received a lot of valuable feedback from the technical reviewers and the process really provided a lot of valuable and constructive insights. What were your main aims when you began writing with us, and how did Packt in particular match those aims? I was aiming to help other people get started with an awesome front-end technology stack (Angular and D3). I love to look closely at topics that interest me, and enjoy exploring all the angles, both practical and theoretical, and helping others understand it. My book experience was great and Packt allowed me to explore all the theory and practical concepts that the target reader will find really interesting. What was the most rewarding part of the writing experience? The most rewarding part of writing is getting constructive, critical feedback – particularly readers who leave comments about the book as well as the comments from my reviewers. It was a pleasure to have such skilled, motivated and experienced reviewers on-board who helped me develop the concepts of the book. And of course, holding your own book in your hands after 6 months of hard work is a fantastic feeling. What do you see as the next big thing in your field, and what developments are you excited about? The next big thing will be Angular 2.0 and Typescript 1.5; and this will have a big impact on the JavaScript world. Combining – for example – new Typescript features such as annotations with D3js, opening up a whole new world of writing visualizations using annotations for transitions or styling – which will make the code much cleaner. Do you have any advice for new authors? Proper planning is the key, it will take time to write, draw graphics and develop your code at the same time. Don't cut a chapter because you think you don't have time to write it as you wanted – find the time! And get feedback as soon as possible. Experienced authors and users can give very good tips, advice and critique. You can connect with Christoph here: Github: https://github.com/chaosmail Twitter: https://twitter.com/ChrisiKrnr LinkedIn: https://ch.linkedin.com/in/christophkoerner Blog: http://chaosmail.github.io/ Click here to find out more about Christoph’s book Data Visualization with D3 and AngularJS

Heather Mahalik is currently Principle Forensic Scientist and Program Manager at Oceans Edge, Inc, and the course lead for the SANS mobile device and advanced smartphone forensics courses. With over 11 years' experience in digital forensics, she currently focuses on mobile device investigations, forensic course development and instruction, and research on smartphone forensics. As a prolific forensics professional, Heather brought a great deal of expertise and knowledge to Packt, helping to make Practical Mobile Forensics a great success, and we caught up with her to get some thoughts on her experiences as an author. Why did you decide to write with Packt, what convinced you? Packt approached me with the idea and introduced me to the other authors, who ended up being co-authors of the book. I was lucky to be sought out and not have to seek a publisher. As a first-time Packt author, what type of support did you receive to develop your content effectively? Packt provided our team an editor and others to support our efforts on the book. Our Acquisition Editor was fantastic and always responded immediately. I never felt that any question was unanswered or that I didn’t have the support I needed. They were also very flexible with us submitting chapters out of order to allow the normal flow of writing. What were your main aims when you decided to write a book, and how did Packt, in particular, match those aims? I wanted to release a book quickly on mobile forensics that emphasized the use of open source tools. Packt allowed us to progress quickly, update as needed and get the book out. What was the most rewarding part of the writing experience? Working with my co-authors. Seeing their perspectives on each topic was eye opening. What do you see as the next big thing in your field, and what developments are you excited about? Handling smartphone security – device security, encryption, and application obfuscation. Do you have any advice for new authors? Stay positive, write a little bit every day and hang in there. Follow Heather on Twitter (@HeatherMahalik) or take a look at her blog. If you have been inspired to write, get in touch with our experienced team who are always open to discussing and designing potential book ideas with talented people. Click here for more details.

Lorenzo Bettini is an Assistant Professor in Computer Science at the Department of Informatics at the University of Turin, Italy, and the author of Implementing Domain-Specific Languages with Xtext and Xtend. You can learn more about Lorenzo here and here. You can also find him on Twitter: @lorenzo_bettini We spoke to him about his book and his experience of writing it, and found out a little more about his research and daily work… How will readers benefit from this book? Did you learn anything new while writing the book? At the time I started writing the book (and also currently) there was no other book on Xtext (at least in English). For this reason I hope that new users of Xtext can benefit from it: following it chapter by chapter they should be able to get acquainted with this cool and powerful framework. My intention was also to describe my own experiences with Xtext (I've been using it for several years, since version 0.7), in particular I tried to describe some programming techniques and best practices. My two favorite chapters are the one on Testing (Testing your software is truly crucial, and DSLs implemented in Xtext are definitely no exception; the whole book is based on tests) and the one on Scoping (Scoping is one of the most difficult concepts in Xtext, but it is also one of the most important; I hope I managed to describe scoping so that it is easier for readers to understand). For these reasons, I hope that also readers who are already familiar with Xtext can learn something new. Our authors usually have full-time jobs whilst writing for us. Was this the case for you and how did you manage your time? I am a full-time Assistant Professor (Researcher) in Computer Science; this might sound like I have lot of spare time but that's not the case: we too have lots of deadlines… However, since I've always used Xtext for implementing the languages I'm doing research on, the time I spent on the book has been a real scientific investment for me. During the writing process, did you come across any issues/ difficulties that affected your writing and how did you overcome these? Especially for the more advanced chapters I was kind of blocked at least on some example implementation. The authors of the Xtext framework were really available and they helped me solving such issues (not to mention that two of them, Jan Koehnlein and Sebastian Zarnekow, also reviewed the book). I'm really grateful to all of them (especially for creating Xtext) Was there anything interesting that happened during the writing of the book? Well, when I started to write the book, Xtext was version 2.3... After writing half the book, Xtext 2.4 was released. The new release created a new version of the projects (Xtext comes with project wizards that setup most of the things to get you started), in particular, Xtext 2.4 started to rely mostly on Xtend (a Java-like language, completely interoperable with Java and its type system). This meant that all the examples had to be rewritten, and also many parts of the chapters that had been already delivered. I think that this makes the code of the examples (also shown in the book) much more readable, and that's why the title has been changed so that “Xtend” appears in the title as well. How did you find the overall experience of writing your book for Packt? It was a lot of stress, but also a whole lotta fun in the end! What disturbed me most was that I had to use WYSIWYG editors like LibreOffice and Word... I use LaTeX type setting system all the time; LaTeX is so powerful once you learned it that it was a real shock (and nightmare) to fight against the rigidity of Word. What tools or configuration do you use for your workstation? I've been a Linux user for decades, and I've written the book on a very pleasant Linux Mint distribution. I only had to switch to Windows to deal with some problems in the files that required Word instead of LibreOffice. Thanks Lorenzo! If you want to learn more about Xtext and Xtend, you can buy Lorenzo’s book here. Packed with plenty of examples it’s been designed to give readers a practical and accessible insight into a complex area of development.

If you're not sure what Spring Boot is exactly, or why it's becoming such an important part of the Java development ecosystem you're in the right place. We'll explain: Spring Boot is a micro framework built by the team at Pivotal that has been designed to simplify the bootstrapping and development of new Spring applications. To put it simply, it gets you up and running as quickly as possible. Greg Turnquist has has significant experience with the Spring team at Pivotal for some time - which means he is in the perfect position to give an insight on the software. We spoke to Greg recently to shed some light on Spring Boot, as well as his latest book Learning Spring Boot 2.0 - Second Edition. Greg on tweets as @gregturn on Twitter. Why you should use Spring Boot Packt: Spring Boot is a popular tool for building production-grade enterprise applications in Spring. What do you think are the 3 notable features of Spring Boot that stands apart from the other tools available out there? Greg Turnquist: The three characteristics I have found interesting are: Simplicity and ease to build new apps Boot's ability to back off when you define custom components, and Boot's ability to respond to community feedback as it constantly adds valued features Packt: You have a solid track record of developing software. What tools do you use on a day-to-day basis? GT: As a member of the Spring team, I regularly use IntelliJ IDEA, Slack, Gmail, Homebrew, various CI tools like CircleCI/TravisCI/Bamboo, Maven/Gradle, and Sublime Text 3. How to start using Spring Boot Packt: For a newbie developer, would you suggest getting started with Spring first, before trying their hand at Spring Boot? Or is Boot so simple to learn that a Java Developer could pick it up straight away and build applications? GT: In this day and age, there is no reason to not start with Spring Boot. The programming model is so simple and elegant that you can have a working web app in five minutes or less. And considering Spring Boot IS Spring, the argument is almost false. Packt: How does the new edition of Learning Spring Boot prepare readers to be industry-ready? For existing Spring and Spring Boot developers, what are the aspects to look forward to in your book? GT: This book contains a wide range of practical examples covering areas such as Web, Data Access, developer tools, Messaging, WebSockets, and Security. By building a realistic example throughout the book on top of Java's de facto standard toolkit, it should be easy to learn valuable lessons needed in today's industry. Additionally, using Project Reactor throughout, the reader will be ready to build truly scalable apps. As the Spring portfolio adopts support from Project Reactor, this is the only book in the entire market focused on that paradigm. Casting all these real world problems in light of such a powerful, scalable toolkit should be eagerly received. I truly believe this book helps bend the curve so that people can get operational, faster, and are able to meet their needs. How well does Spring Boot integrate with JavaScript and JavaScript frameworks? Packt: You also work a bit on JavaScript. Where do you think Spring and Spring Boot support for full-stack development with JS frameworks is going ahead? GT: Spring Boot provides first class support for either dropping in WebJars or self-compiled JavaScript modules, such as with Webpack. The fact that many shops are moving off of Ruby on Rails and onto Spring Boot is the evidence that Boot has it all needed to build strong, powerful apps with full blown front ends to meet the needs of development shops. What does the future hold for Spring Boot? Packt: Where do you see the future of Spring Boot's development going? What changes or improvements can the community expect in future releases? GT: Spring Boot has a dedicated team backing its efforts that at the same time is very respectful of community feedback. Adopting support for reactive programming is one such example that has been in motion for over two years. I think core things like the "Spring way" aren't going anywhere since they are all proven approaches. At the same time, support for an increasing number of 3rd party libraries and more cloud providers will be something to keep an eye on. Part of the excitement is not seeing exactly where things are going as well, so I look forward to the future of Spring Boot along with everyone else. Why you should read Learning Spring Boot Packt: Can you give Developers 3 reasons on why they should pick up your book? Are you interested in the hottest Java toolkit that is out there? Do you want to have fun building apps? And do you want to take a crack at the most revolutionary addition made to the Spring portfolio (Project Reactor)? If you answered yes to any of those, then this book is for you.

  How will System Center be used in the next 2 years? Samuel Erskine (MCT), experienced System Centre Admin and Packt author, talks about the future of Microsoft System Center. Samuel shares his insights on the challenges of achieving automation with the Cloud, and effective reporting to determine business ROI.

Jeremy, or Jay, is a Linux Administrator with over 12 years of experience and nine certifications. As a technologist, Jay enjoys all aspects of technology, and when not buried under a plethora of computer books, he enjoys music, photography, and writing. As well as tech books, Jay is also a published fiction author, having written his very own Sci-Fi novel, Escape to Planet 55. Jay's passion for open source software and its long term adoption led him to write Linux Mint Essentials for Packt. We asked Jay to discuss his experience of authoring a technology book with Packt and his insights on the future for open source technology. You can see his answers below and find more information about his books at LINKS. What initially drew you to write your book for Packt Publishing? When Packt approached me to write a book for Linux Mint, I was absolutely thrilled. I have always thought about how cool it would be to write a computer book, but never thought to actually attempt to do it. The thought of having a published book excited me. In addition, I also like very much how Packt donates proceeds back to the project being written about, so it felt good that I would help the Mint community in addition. When you began writing what were your main aims? What did you want your book to teach your readers? We've all been beginners at one point or another. For me, I started using Linux around 2002 when it was very difficult to get used to, and I didn't have much in the way of guidance or insight on how to use it. I stuck with it, and eventually became good at it. For my book, I wanted to make the process of getting accustomed to Linux as easy as possible, and for it to be the reference book I could have used at the time when I started. What did you enjoy most about the writing process and what was most rewarding about the experience of writing? The entire process was very rewarding, and fun. The experience I liked the most about writing was the fact that I was empowered to do it. For me, I like to teach others so I think the most rewarding part for me was the prospect of guiding others to enjoy using Linux as much as I have. If my book has this impact on others, then that will be the most rewarding part. What parts of the writing process were the most challenging and how did you overcome these challenges? The most challenging part of writing about open source software is how frequently it changes. During the writing process, two versions of Mint were released. This required going back to previous chapters and correcting things that were no longer true or had changed in some way. This was overcome by the rewrite phase of the project, where I had a chance to go back through the steps, provide new screenshots, and ensure the content was still compatible. Why, in your opinion, is Linux, or open source software, exciting to discover, read, and write about? Open source software, especially Linux, is extremely fun to learn and write about. I spend hours each day reading blogs, articles, and books, trying to keep up to date. Never does it feel tiring or laborious in any way. During my day job, I manage primarily Linux servers and workstations. When I get home, I read about open source and what's happening. While commuting, I listen to Linux-related podcasts (such as the Linux Action Show, Linux Unplugged, and so on) to keep current on upcoming trends. As I learn, I watch as my workflow changes and improves. While I initially found Linux difficult to learn back in 2002, nowadays I can't imagine my life without it! Why do you think interest in Linux, specifically Mint, is on the rise? I personally feel that Canonical (the makers of Ubuntu) are severely out of touch with what their users, or any user in general, wants and expects from a computing environment. I'm not saying that Ubuntu is a bad distribution, I actually like it. But the fact of the matter is that users have expectations of their computing environment. If these expectations are not meant (regardless of whether the expectations are logical or not) adoption will suffer. Linux Mint takes Ubuntu's base, improves on its weaknesses, and makes it much more convenient for the beginner user. In addition, Mint is scalable – it's perfect for a beginner, and is still very useful for when that beginner becomes an expert. People that care about how the internals of the distribution work will seek to learn about it, while those that don't care just want something that works. Whether you're a general user that just wants to check your Facebook account, or a developer writing the next big application – Mint fits just about every use case. What do you see on the horizon for Linux Mint, and Linux in general? In the short term, I think we'll continue to see Mint grow and expend its user base. Desktop environments, such as Cinnamon and MATE (featured heavily in Mint) will see quite a bit of expansion in the coming years, due to renewed developer focus. In the long term, I can see Mint splitting off into its own complete distribution, away from Ubuntu as its base. While there are no signs of that now, I can see Mint outgrowing its current base and moving off on its own in five years or so. Any tips/stories to share for aspiring/new technical authors? I think the best piece of advice is “yes, you can!” For me, I was very worried about whether or not I would even be good at this. When I sent my first chapter over, I thought the reaction would be that I was horrible and I would be excused from writing. I was really surprised to find out that Packt really liked what I was doing – even assuming that I had done this before! You never know what you're capable of until you give it a shot. I'm glad I did! Even if you're not the best writer in the world (I know I'm not) this is a valuable experience and you'll harness your writing skills as you go. Packt was there for me to work through the process, and it was very rewarding. Another piece of advice I can give is “just start writing.” Don't spend time worrying about how to write, what to say, or any of those bad things that can lead to writers block. Open up a word processor, or even a text editor, and just start writing something. You can always go back and correct/revise your sentences. The trick is to get your brain working, even if you don't plan on using what you're writing at that very minute. Just keep your mind busy and the rest will follow. Another important tip, which may seem like common knowledge to some, is to use some sort of versioning backup for your directory which includes your book files. A simple periodic copy to a flash drive or removable media isn't going to cut it, you want something that not only backs up your files but also allows you to go back to previous versions of a document in case you blow away content you didn't mean to. Examples of this include Dropbox, or Crashplan, though I'd recommend SpiderOak a bit more for its focus on security, a higher feature set, and the ability to sync between machines. All three are multi-platform.

Mario Casciaro is a software engineer and technical lead with a passion for open source. He began programming with a Commodore 64 when he was 12, and grew up with Pascal and Visual Basic. His programming skills evolved by experimenting with x86 assembly language, C, C++, PHP, and Java. His relentless work on side projects led him to discover JavaScript and Node.js, which quickly became his new passion. Mario now works in a lighthouse at D4H Technologies, where he led the development of a real-time platform to manage emergency operations (Node.js to save lives!). As Mario is at the cutting-edge of Node development, we asked him to share his thoughts on the future of his field, and also on what led him to want to write a book with Packt.   Why did you decide to write with Packt, what convinced you? I already knew Packt from some excellent books I read in the past and that was certainly a good start. As an author I was given a lot of freedom in the definition of the contents of my book and this was probably what I liked the most as it allowed me to leverage my knowledge and passion at its fullest. Besides that, Packt has one of the best royalties package out there, something to not overlook. As a first-time Packt author, what type of support did you receive? Packt provided me with some interesting education material, and besides the mandatory style guide, there were some articles with advice on how to organize the work and deal with the ups and downs of the writing process. However, what was most helpful was the patience of the editors in providing feedback and fixes, especially during the writing of the initial chapters. I think this is a make-or-break factor as the first 2/3 months are probably the toughest and it's important to have the support of an empathetic team to succeed. What were your main aims when you began writing? My main goal was to write a book worth reading, something that I would have bought and read myself if I wasn't the author. One of the things I wanted to avoid was to include trivial content, knowledge that could easily be found elsewhere, such as in a good free tutorial or in some official documentation. I wanted every topic to teach the reader something new, I wanted to 'wow' the reader with content and notions it was unlikely they knew before. What was the most rewarding part of the writing experience? Reading a message from a reader saying 'thank you' is probably the most rewarding part of being an author. It brightens up my day and reminds me that the time writing the book was well spent. In general, knowing that I helped somebody learn something new and valuable is an amazing feeling. What do you see as the next big thing in your field, and what developments are you excited about? JavaScript is taking over the world, it is spreading well beyond the browser and the web. This change is already happening, we can use JavaScript to implement server applications (node.js), in databases (couchdb), in connected devices (tessel), on mobiles (phonegap) and on desktops (nw.js). I'm also looking forward to the spreading of the new ES6 and ES7 standards which should add even more powerful features to the language. Do you have any advice for new authors? Dream big but keep it simple. If you want to explain complex topics always start from the basic notions and build on top of those as you move forward. Always assume there might be some reader that doesn't have a prior knowledge to completely grasp a concept or a code sample. Spend a few words on the background of a problem/solution, why the reader should learn it and what advantages it brings. No one likes to be fed with knowledge without knowing why. On the organizational side, I would say that the most important aspect is sticking with the schedule, no matter what. Build the habit of writing for the book at a given time of the day and move away from the computer screen only when you spent all your mental energy. For me, that was the most rewarding moment of the day, knowing that I’ve done my job and that I couldn’t have done more. Always focus on the current chapter, try to get it as much production-ready as you can (there will be little time to change things later), don’t think to the amount of work left to finish the book, one chapter at the time you will have achieved what you previously considered impossible. Follow Mario on Twitter, connect with him on Linkedin, or find him on Github. You can buy Mario’s book Node.js Design Patterns from packtpub or find out more about the book here: http://www.nodejsdesignpatterns.com If you have been inspired to write, get in touch with our experienced team who are always open to discussing and designing potential book ideas with talented people. Click here for more details.

David Dossot is a highly experienced software engineer and architect of close to two decades. Armed with knowledge of RabbitMQ gathered since 2009, he has written a fantastic book called RabbitMQ Essentials, a fast-paced tutorial that covers the fundamentals of RabbitMQ when used in Message Queuing. As a renowned developer, we asked David to share with us his approach to and experience with authoring a technology book with Packt. We also asked him for some of his insights and running thoughts on the current state and future development of RabbitMQ and Message Queuing. You can see his answers below and find more information about his book here. Q. What initially attracted you to write your book for Packt Publishing? Packt Publishing approached me with a project for a RabbitMQ book. Since it's a technology I know quite well and appreciate a lot, and because the time was right, I decided to embark upon the adventure. Moreover, having never worked with Packt before, I was curious to experiment with a new publishing workflow. Q. When you began writing, what were your main aims? I wanted to produce a short book that would have a mix of high-level concerns, like architectural principles around messaging, and low-level concerns, like the technical details involved in dealing with RabbitMQ. I also wanted to make the book easy to read by telling the story of a fictitious company discovering RabbitMQ and rolling it out up to production. Q. What did you enjoy most and what was most rewarding about the experience of writing? I really enjoyed the pace at which the book was produced: three months of writing and an extra month of revisions and production was the fastest project I ever worked on. Progressing at such speed, without sacrificing the quality of the end product, was extremely rewarding. Q. Why, in your opinion, is RabbitMQ exciting to discover, read, and write about? RabbitMQ is an open source project with a very active community: I'm convinced that open source can use any coverage it can receive, so writing a book about it was a way for me to pay back a little for the great piece of software I have been using for free. Moreover, though there were already many excellent books written about it, none had the brevity and mix of high- and low-level concerns I was envisioning for my book. Q. What is different about RabbitMQ from other open source message queuing software? The richness and interoperability of the AMQP protocol is an important factor for RabbitMQ's success. Another important factor is the solid engineering and sound design decisions that have been made by RabbitMQ's creators. The fact that it's built on Erlang brings some extra guarantees in terms of stability. Finally, the RabbitMQ team is excellent at offering powerful and complex features in an easy package: this is far from the norm in our industry. Q. What do you see on the horizon for RabbitMQ and message queuing, as a whole? RabbitMQ's popularity will keep rising, especially via cloud offerings that relieve users from the tedium of maintaining their own servers. In general, the usage of message queuing is poised to increase as developers become more and more aware of the principles at play when building scalable applications. The recent Reactive Manifesto (http://www.reactivemanifesto.org/), which somewhat rehashes and refreshes old principles of software design, emphasizes the necessity to decouple application components: message queuing is one of the main ways to achieve this. Q. Any tips for new authors? Writing a book is a fractal process where you proceed in several passes, with a higher level of details each time. The following approach has worked very well for me so it may work for others too: Start with the table of contents (TOC): write down the main ideas for each chapter and pay attention to the overall narrative, making sure that ideas develop progressively and logically When you write a chapter, start by copy/pasting the ideas from the TOC and flesh them out a little: don't write sentences yet but instead drop in notes and ideas for figures Prepare the code samples and capture screenshots of executing applications at that time Now you're ready for the last pass: finalize the chapter by writing the complete text and creating any extra diagrams needed Here are a few extra tips: Do not write in order: write paragraphs and even chapters in the way you feel most inspired to. This can relieve you from author's block. The first chapter is the hardest to write: get ready to come back to it several times. Find some music that helps you write: sometimes when you’re be tired and have a hard time getting started, music can get you back on track.

Claire Chung is a PhD student at the Chinese University of Hong Kong researching bioinformatics. She is also one of the authors of Matplotlib 2.0 by Example. We spoke to Claire about her experience in tech, and her book. She offered a unique perspective on gender issues in the industry as well as wider questions of accessibility and the future of research and how technology will continue to change the way we make scientific discoveries. Packt: What’s the most interesting thing/key take away from your book? Claire Chung: Good storytelling is crucial even for the best data crunching results. Data visualization determines whether you can actually get the message across in presentation. This is true not just for the Tech field, but in any workplace setting - to persuade your clients, your boss, or simply to communicate objective quantitative concepts to fellow scientists or even the general public. Many people around feel scared when it comes to the word ‘code’, or think that numbers alone can provide a complete picture, so sometimes they turn to unsuitable plots that are easily produced with common software, leaving them not customized. We want to tell everyone the right plot and refinement of your data graphics do matter, and it doesn’t take superb programming skills or expensive software to create brilliant data visualization. Packt: Tell us about your experience in the Tech sector, how did you get where you are today and how did you come to write your book with Packt? Did you experience any setbacks along the way? CC: How I went from a bioinformatics lab to writing a Packt book with a lab alumnae today is a bit like joining dots together. Computers have interested me since I was small, because the internet opened up a brave new world of unseen knowledge that was free for me to explore. Moreover, I find huge fun and satisfaction in using logic and creativity in problem solving. I remember persuading my mum at a younger age to let me replace the graphic card based on my own diagnosis, instead of paying double for just a check excluding repair fee, and solved the issue swiftly. Whenever there are technical problems, family, teachers and friends would usually come to me. I enjoy helping them fix the issues, with explanations so they understand how to deal with similar situations. At that time, I did not particularly aspire to be in the Tech field. Sometimes I think that if I wasn’t a scientist, I might have been a dancer or tour guide or anything else. However,  with my curiosity focused on exploring the fascinating deep mysteries of life, I chose to read Cell and Molecular Biology in college. During my undergraduate study, I saw that the Campus Network Support Team in the IT department of my college was recruiting student helpers. I took the opportunity to test self-learnt skills, and gratefully was accepted after the apt-test and interview. While most members naturally come from the Computer Science and Engineering faculty, and were mostly male, I observed a very good work culture there. Everyone was friendly with and willing to learn from each other, regardless of fields of study, education background, gender or anything else. We became good partners at work and good friends in life. Later, I had the privilege to be appointed as leader of the team, responsible for coordinating team effort, recruitment and training of new members, as well as communicating with senior staff and operators in providing support service. This friendly atmosphere and valuable experience play a part in giving me confidence to work in the Tech field and faith that a bias-free friendly environment is totally achievable. In pursuing my studies in life science, I found out that biological data plays a huge role in driving data science. Traditional approaches of genetic research, for instance, study gene actions one by one. Not only is this largely time and labour intensive, we can easily miss the big picture of the network of interactions between genes and different components in the multiple layers of regulations.  Like other Tech fields, technological advancement makes it much easier to generate data, computational power has also increased exponentially in recent decade to power, but data analysis is still at bottleneck. The amount of skilful analysts cannot keep up with the immeasurable data generated each day. While we do not replace traditional studies being of different scope and the basis of research in any scale, there is much more effort needed to innovate for better delineating biology, the workings of life. Packt: How has the industry changed since you started working? Do you think it is getting easier for people from different backgrounds to get into the Tech world? CC: I am working in bioinformatics and have met people in all walks of life getting into Tech. In my point of view, it is certainly evolving into a more open field. Decades ago, programming and data analysis skills used to be vocational expertise. Computer engineering students graduate into programmers in companies. They mostly work in technology-dedicated companies, or are appointed or sent to attach to existing departments on demand. This model still persists, but I have also observed a large paradigm shift nowadays. Companies are hiring more people from diverse background. Startups and new teams in large corporations with high degree of freedom keep emerging. I have friends with art training developing UX award entry apps. I met people with physics, chemistry and civil engineering education and various level of coding background in the same team when speaking in a Tech conference. Today, like how typists have almost disappeared entirely, office productivity software usage is expected as much as basic English writing and arithmetic, basic programming skills are gradually become some sort of literacy. In my case, I am working in a lab among the first established bioinformatics lab in Hong Kong. Not long before I enter the lab, there are so few bioinformaticians, that coming to our lab is one of the very few local options to go when you want to analyse any sequencing data at all. Today we still present an obvious edge in being the most familiar with these techniques, to critically assess and provide solutions to different studies, and hence the most ready to further explore beyond basic analysis, so my supervisor continues to help us select collaboration to get the most interesting questions answered. On the other hand, with increasing availability of courses on bioinformatics and data science, user-friendly packages for data analysis, laboratories are able to hire students who are willing to learn from trial-and-error, or purchase commercial services for basic or routine analyses. While knowledge and techniques set the concrete foundation for anything to build on, I feel that there are no more technical skills that are irreplaceable life-long. Innovation, human-related and overall management skills make the difference. I was really a sidekick at the time I started; there were only two girls including myself. But guess what? We have more or less even males and females joining as regular students now. Packt: What are the biggest misconceptions about working in the Tech sector today? CC: I think the biggest misconceptions are “I am not …, I will never do/understand it”. But more specifically, there seems to be a belief that you must hold a degree in Computer Science or Engineering in order to start your career in the Tech sector today. However, this concept probably isn't as strong in the field as it is outside. Many people outside the field got extremely curious, how I am working in front of computers as a student under a biology programme. While formal major study is undeniably the most direct way to obtain solid foundation of knowledge and to enter the field, it is not a definite ticket to success in the industry. The reverse is true as well. The “Tech field” today is not a shrouded dome. It is a hub where people pass through in getting to their destination. You can start off with a strong computation background, and that can help you land on many different areas. Besides the low-cost learning materials around mentioned, more and more attachment programmes are welcoming aspiring apprentices to bring in new sparks. Think in the other way, starting with less releases you from high opportunity cost. You can also invest & publish your work on GitHub or app stores. Results speak it all. I believe fresher minds on holiday embarking today can probably come up with more brilliant ideas, than I can do with limited time outside my PhD study. We should not be intimidated by things like “I am not white”, “I am not a guy”, “I have not tried this before”, etc. Instead, think of “how you will work it out”. We also should not be bounded by stereotypes against ourselves or anyone else. Personal non-work related qualities and hobbies are irrelevant to ability. (I always wear dress or skirts around in campus or in tech conferences simply because I like it.) Of course, we never need the whole world to work in the same sector, which is not healthy for individuals and society at all. Just don’t set a limit for ourselves. If you want to dive in, be prepared. Then “knock, and the door will be opened.” Packt: What do you think the future looks like for people working in the Tech industry? Will larger companies strive to make it more accessible to everyone? CC: I think the future of the Tech industry will get ever more open and competitive. Will larger companies strive to make it more accessible to everyone? Sure. I think they are doing so even right now. Look at the moves taken at Google cloud platform, Mircosoft STEM resources and NVIDIA’s deep learning institute, just to name a few, including online courses they sponsored. The industry is always in thirst of talent. More open resources bring in more brilliant minds to keep advancement. As discussed, there will no longer be a clear gap set by hours spent or grades obtained in classroom, but willingness to learn and apply actively. Even for people with the strongest formal engineering training, this is the attitude that will push them forward towards far greater success. I am looking forward to seeing more vibrant energy in the field in coming future. Thanks for chatting with us Claire! Check out Matplotlib 2.0 by Example here. Or explore more data analysis resources here.

Scott Kildall is an artist whose work often explores themes of future-thinking and translation between the virtual and the real. His latest projects use physical data visualization - the transformation of data sources into physical objects via computer algorithms. We're currently collaborating on the Polygon Construction Kit, a software toolkit for building physical polygon structures from wireframe 3D models. I caught up with Scott to ask him about his work and how 3D printing and digital fabrication are changing the production of artwork. How would you describe your work?I write computer algorithms that generate physical sculptures from various datasets. This has been a recent shift in my art practice. Just five years ago, digital fabrication techniques, 3D printing, CNC machinery and other forms of advanced fabrication were simply too expensive for artists. Specifically, I've been diving into what the media ominously calls "big data," which entails thousands upon thousands of data points ranging from city infrastructure data to biometric feedback. From various datasets, I have been generating 3D-printed sculptures. Water Works - Imaginary Drinking Hydrants (2014) 3D-Printed Sculpture with laser-etched wood map What are some of the tools that you use?I write my own software code from the ground up to both optimize the production process, and create a unique look for my work. My weapon of choice is openFrameworks, a C++ toolkit that is relatively easy to use for a seasoned applications programmer. The other open source tool I use is Processing, which is a quick and dirty way to prototype ideas. Python, my new favorite language, is excellent for transforming and cleaning datasets, which is the not-so-glamorous side of making "data art". You've just completed some residencies and fellowships, can you tell us about those?In 2014, I was an Artist In Residence at Autodesk in San Francisco, where I live. Autodesk has an amazing shop facility including 6 state-of-the art Objet 500 printers. The resulting prints are resin-based and capture accurate details. During a several month period, I was able to iteratively experiment with 3D printing at a rate that was much faster than maintaining my own extrusion 3D printer. Data Crystals (2014) Incidents of Crime Data from San Francisco The first project I worked on is called Data Crystals, which uses public data sets from the city government of San Francisco, which anyone can download from the data portal at SFGov.org. The city's open data includes all sorts of goodies such as geolocated points for incidents of crime and every parking meter in the city. I mapped various data points on an x-y plane using the latitude and longitude coordinates. The z-plane was then a dimension of time or space. To generate the "Crime Data" crystal, I worked with over 30,000 data points. My code represented each data points as a simple cube with the size being proportional to the severity of the crime. I then ran clustering algorithms to create one cohesive object, which I call a "crystal", like a synthetic rock that a data miner might find. In a sense you're mining an abstract data source into a physical object...It was more like finding a concrete data source and then turning it into an abstract physical object. With conventional 2D data visualizations you can clearly see where the hotspots of crime, or other data points, might be on a map. However, the Data Crystals favor aesthetics over legibility. The central question I wanted to answer was "what does data look like?" When people create screen-based data visualizations, they focus on what story to tell. I was intrigued by the abstract data itself and so made art objects which you could look at from different vantage points. What is it about having the data occupy a physical space that's important to you?When data occupies a physical space, it is static, like a snapshot in time. Rather than controlling time, like you would on a slider with a screen-based visualization, you can examine the minutiae of the physical characteristics. The data itself invites a level of curiosity that you don't get with a mediated screen-based interaction. Real objects tap into the power of conventional perception, which is innate to how our brains interact with the world. Tell us a bit about your series of sculptures that were created in the virtual world of Second Life and then physically created using Pepakura software and papercraft techniques.An earlier project that I worked on, in collaboration with my partner Victoria Scott, is No Matter (2008). This project was instrumental in my development about how to transform the imaginary into the real. For this project, we worked with the concept of imaginary objects, which are things that have never physically been built, but exist in our shared imagination. They include items from mythology like the Holy Grail or the Trojan Horse, from fiction like the Maltese Falcon or the Yellow submarine, or impossible objects/thought experiments like the Time Machine or Schrodinger's Cat. We constructed these objects in the imaginary world of Second Life and then extracted them as "digital plunder" then rebuilt them as paper sculptures in real space. No Matter (2008) Second Life Installation at Ars Virtua No Matter (2008) Yellow Submarine paper sculpture Because they were paper sculptures that were physically fabricated, there were physical constraints such that the forms themselves had to be vastly simplified to smaller faceted objects. The collision between this faceted proto-object with beautiful high resolution prints resonate with most viewers on an aesthetic level. Working with that kind of virtual space led me to thinking about the question of data -- could this intangible "thing" also be represented materiality? No Matter (2008) Installation at Huret & Spector Gallery What are you working on now?I'm developing a new project called Machine Data Dreams, which examines the question of "how do machines think?" To make computers function, humans program code in languages such as JavaScript or Python or C++. There are whole sets of people that are literate with these machine languages, while most others in the world don't "speak" them. Knowing how to code gives you power and money, though usually not prestige. However, understanding how machines process language will be increasingly important as they will undoubtedly be increasingly integrated with human biology. My proposition is to create a room-based installation that reflects the structure of language and how machines might view the world through a datasets representing machine syntax. What I will be doing is taking machine language (e.g. Javascript, Python, C++) and translating that to a language-based data sets. From these, I will algorithmically generate a cavelike 3D model with triangulated faces. The Polycon Construction Kit -- which you developed -- will be instrumental in making this happen. Last year, I had sketched out ideas in my notebook about creating custom 3D-printed connectors for large-scale sculptural installations, and then I found out that you had already been working on this technology. So, thank you for inviting me to collaborate on Polycon! I'm grateful to be figuring out how to do this with a trusted colleague. What are some of the trends or new technologies that you're excited about?There's so much happening in field of digital fabrication! For example, 3D printing technology has so much to offer now, and we're at a pioneering stage, akin to Photoshop 1.0. Artists are experimenting with the medium and can shape the dialog of what the medium itself is about. It's clear to me that 3D printing / 3D fabrication will be a larger part of our economy and our universe. It fundamentally changes the way materials are produced. Many have made this observation, but it is still understated. 3D printing is redefining the paradigm of material production, which also affects art production and factory production. This is how capitalist-based economies will operate in the next 20 or 30 years. From an artistic standpoint, working with digital fabrication technology has changed the way I think about sculpture. For example, I can create something with code that I never thought was even possible. I don't even know what the forms will look like when I write the code. The code generates forms and I find unexpected results ranging from the amazing to the mediocre to the crappy. Then I can tweak the algorithms to focus on what works best. You've had a chance to work with some of the most advanced technologies through the Autodesk residency. Now you have your own 3D printer in your garage. Do you see a difference in your creative process using the really high-end machines versus something you can have in your garage? Working with the high-end machines is incredible because it gives you access to making things as perfect as you can make them. I went from working with printers that probably cost a half a million dollars to a printer that I got for $450. Like half a million to half a thousand?Yes! The Autodesk printers are three orders of magnitude more expensive. The two types of printers have vastly different results. With my garage setup, I have the familiar tales: messed up 3D prints and the aches and pains of limit switches, belts and stepper motors. I've been interested in exploiting the glitches and mistakes. What happens when you get bad data? What happens when you get glitchy material errata? My small extrusion printer gives me a lot more appreciation for fixing things, but when making something precise I'd much rather work with the high-quality 3D printers. Where can we see more of your work?All my work is on my website at http://kildall.com. My blog at http://kildall.com/blog has my current thought processes. You can follow me on Twitter at @kildall About the Author: Michael Ang is a Berlin-based artist and engineer working at the intersection of art, engineering, and the natural world. He is the creator of the Polygon Construction Kit, a toolkit for bridging the virtual and physical worlds by translating simple 3D models into physical structures.

Max Kanat Alexander understands software implicitly. He has spent his career not only working with it, but thinking about it too. But don't think for a moment that Max is an armchair philosopher. His philosophy has real-world consequences for all programmers, offering a way to write better code and achieve incredible results while remaining happy and healthy in an industry that can be exhausting.  In his new book Understanding Software Max explores a wide range of issues that should matter to anyone working with software - we spoke to him about it, and discussed his thoughts on how thinking about software can help us all.  You're currently working at Google. Could you tell us what that's like and what you're working on at the moment? Max Kanat-Alexander: I can't answer this question in a public setting without approval from Google PR. However, there is a public blog post that describes what I do and provides my title. Why simplicity is so important in software Your last book was called “Code Simplicity” – could you tell us exactly what that means and why you think it’s so important today? MKA: One of the things that I go over in that book, and that I cover also in my new book, is that most of the problems of software fundamentally come from code complexity. Even when it doesn't seem like they do, if you trace down most problems far enough, you'll see that they never would have happened if there hadn't been so much code complexity. This isn't obvious to everybody, though, so I wrote a book that provides a long reasoned argument that explains (a) the fundamental laws of software design and (b) hopefully brings the reader to understanding why simplicity (and maintaining that simplicity) is so important for software. I figured that one of the primary causes of complexity was simply the lack of full and complete understanding by every programmer of what complexity really is, where it comes from, why it's important, and what the simple steps are that you take to handle it. And even now, when I go back to the book myself, I'm always surprised that there are so many answers to the problems I'm facing now. When you've discovered the fundamental laws of software development, it turns out that they do in fact resolve problems even long after their discovery. Do you think you can approach code the same way whatever languages or software you’re using? Is there a philosophy you think any engineer can adopt? Or is flexibility key? MKA: There are fundamental laws and principles that are true across any language. Fundamentally, a language is a way of representing a concept that the programmer has and wants to communicate to a computer. So there are ways of structuring concepts, and then there are ways of structuring things in a language. These both have rules, but the rules and principles of structuring concepts are the senior principles over the rules for structuring things in a language, because the rules for how you organize or handle a concept apply across any language, any computer, any set of tools, etc. Theoretically, there should be an ideal way to represent any particular set of concepts, but I'm not sure that any of our languages are there yet. The philosophy I've expressed in Code Simplicity and now in Understanding Software is entirely a universal philosophy that applies to all software development. I don't generally write about something if you can only use it in one language or with one framework. There is enough of that sort of writing out in the world, and while it's really valuable, I don't feel like it's the most valuable contribution that I personally have to bring to the world of software development. Since I have a background in some types of philosophy as well as a lot of experience doing design (and extensive refactoring) across many languages on many large projects, there's a universal viewpoint that I've tried to bring and that a lot of people have told me has helped them. To answer your last question, when you say the word "flexibility," you're in dangerous territory, because a lot of people interpret that as meaning that you should write endless generic code up front even if that doesn't address the immediate requirements of your system. This leads to a lot of code complexity, particularly in larger systems, so it's not a good idea. But some people interpret the word "flexibility" that way. For a more nuanced view, you kind of have to read all of Code Simplicity and then see some of the newer content in Understanding Software, too. Are there any languages where code simplicity is particularly important? Or any in which it is challenging to keep things simple? MKA: More than for a particular language, I would say it's important for the size and longevity of a project. Like, if I'm writing a one-off script that I'm only going to use for the next five minutes, I'll take a lot of shortcuts. But if I'm working on a multi-million line codebase that is used by millions of people, simplicity is of paramount importance. There are definitely languages in which it's more challenging to keep things simple. I've made this statement before, and there are a lot of amazing developments in the Perl community since I first made it, but it was a lot of work to keep the Bugzilla Project's Perl codebase healthy when I worked on it--more so than with other languages. Some of that had to do with the design of that particular codebase, but also that Perl allows you to accomplish the same thing in so many different ways. It led to a lot more thorough and time-consuming code reviews where we would frequently have to tell people to do things in the way that our codebase does them, or the particular way that we'd learned was the most maintainable through hard-earned experience. It did still result in a well-designed codebase, and you can write well-designed Perl, but it required more language experience and more attention in code review than I've experienced when writing in other languages. Bash is similar in some ways--I once maintained a several-thousand-line Bash program, and that was pretty challenging in terms of simplicity.  Languages aren't equal--some are better than others for some types of tasks. There are tasks for which I love Perl and Bash, and others for which Java, Python, or Go are definitely more suitable. Some of this has to do with the suitability of a particular tool to a particular task, but more of it has to do with things like how much structure the language allows you to place around your code, how much consistency the language libraries have, etc. What makes code bad? What, in your opinion, makes code ‘bad’? And how can we (as engineers and developers) identify it? MKA: It's bad if it's hard to read, understand, or modify. That's the definition of "complex" for code. There's a lot to elaborate on there, but that's the basic idea. What do you think the main causes of ‘bad code’ are? Lack of understanding on the part of the programmer working on the system. A failure of the programmer to take sufficient responsibility for enough of the system. A simple unawareness of the problem. On your blog you talk a lot about how code is primarily ‘human’. Could you elaborate on that and what it means for anyone that works in software?  Sure. It’s people that write software, people that read it, and people that use it. The whole purpose of software is actually to help people, not to help computers or network cables. When you're looking at solving the problems of software development, you have to look at it as a human discipline--something that people do, something that has to do with the mind or the being or the perceptions of individuals. Even though that might sound a bit wishy-washy, it's absolutely true. If you think of it purely as being about the computer, you end up writing compilers and performance tools (which are great) but you don't solve the actual problems that programmers have. Because it's the programmers or the users who have problems--not the machines, for the most part. You have to talk to people, find out what's going on with them. Just as one example, one of the best ways to detect complexity is to ask people for negative emotional reactions to code. "What part of this codebase is the most frustrating?" "What part of this codebase are you the most afraid to touch because you think you'll break something?" Questions like that. And those are basically questions about people, even though you're getting data about code. Because when you come down to it, the whole reason you're getting data about code has something to do with people. You can't lose sight of the fact that the problem you're resolving is code complexity, but at the same time, you also can't forget the reason you're resolving it, which is to help programmers. How has your thinking around code changed over the years? Are there any experiences that stand out as important in shaping your philosophy today? MKA: I've always been fairly meticulous in terms of how I want to approach code. However, it's also important that that meticulousness delivers a product. There have been times, particularly in my early coding career, when I would go to clean up some codebase or improve something only to find that nobody actually wanted the end result. That is, you can work on a project for a long time that nobody actually ends up using or caring about. So one of the lessons that I learned, which is expressed in both Code Simplicity and Understanding Software, is that your software has to actually help somebody or you're not going to actually end up being very happy with it, even if you enjoy the process of working on it. Also, the more time I spend working with groups of engineers as opposed to working alone or in distributed teams, the more I learn about how to communicate the basic principles of software development to other engineers. I think that Code Simplicity did a pretty good job, but weirdly, sometimes you can be too simple for some people. That is, if you get too fundamental with your explanations, then sometimes people don't see how to use the information or how it applies to their life. Sometimes you have to get a bit more complex than the fundamentals, explain a bit more about how to use the data or how it might apply in some specific situation, because some programmers are very focused on their specific problem in present time. That is, they don't want to hear about how to solve all problems like the one they're having - they can't even listen to that or really digest it. So instead you have to frame your explanation in terms of how it applies to this specific problem, which--when you're coming from the fundamental laws of software design all the way up to some extreme complexity that some programmer has boxed themselves into--can become quite difficult to fully communicate. It's also tough because they often think they already know the fundamentals, even though the problem they're having clearly indicates that they don't. So you have to learn how to communicate around those barriers. Working on the Bugzilla Project was a significant influence in how I think about software development, because I proved that you really can refactor a legacy codebase that's gotten into a very bad or very complex state, and that that has significant effects on the product. I think that's one of the things that's been missing in other attempts or writings, is that there's a lot of talk about how code quality is important, but I (and the people who worked with me on Bugzilla) actually went through the process of making significant impacts on products and users over a period of many years by focusing almost purely on code quality and applying the basic principles of software design. There have been lots of other experiences that have been an influence. I think that I generally try to learn something from every encounter I have with programming or software engineers. It's dangerous to think that you already know everything already--then you stop learning. 3 things to take away from Understanding Software What are the three things you want people to take away from Understanding Software? Well, I hope that they take at least as many things away from the book as there are chapters in the book. But in general, I'd like people to have some good ideas about how to handle problems that they run into in terms of code complexity. I'd also like them to understand more about the fundamental reasons that we handle code complexity, as well as the rules around it. I'd like people to see the basic philosophy of software development as something that they can think with themselves, not just something that somebody else has said, and I'd like them to be able to use that basic philosophy to resolve the problems of their software development environments. And of course, I'd like people to come away from the book being much better and faster programmers than they were before.  3 ways engineers can be more productive What 3 tips can you give to developers and engineers who want to be more productive?   1. Understand as much as you can about software, the project you're working on, etc. See the chapter "Why Programmers Suck" in Understanding Software for all the details on this and other things that you should learn about.   2. Try to take responsibility beyond the normal bounds of your code. That is, if you're normally only responsible for one tiny part of the system, also start thinking about how you could improve the parts of the system that talk to your part. Think about the consumers of your code and work to refactor them as well, when necessary. Keep expanding your sphere of responsibility over your codebase over time, even to the point of helping out with the tools and languages that you use to develop software, eventually.   3. Stop thinking so much about your code and start coding more. Or do drawings, or take a walk, or talk to somebody, or something. See the chapter "Stop Thinking: The Secret of Fast Programming" in Understanding Software for the full details on this.