Author Posts

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.

School of Code is a company on a mission to help more people benefit from technology. And Packt are delighted to support the initiative. Empowering people to master code and feel confident developing software is central to Packt's mission, so it is fantastic to partner with an organization doing just that in the West Midlands.  We were lucky enough to speak to Nazia Choudrey who has been involved with the School of Code bootcamp. She told us about her experience with the initiative, and her perspective on what tech is like today for women and people of color.  Packt: Hi Nazia! Tell us a little about yourself. Nazia Choudrey: I am a person who is trying to re-invent myself. Just over a year ago I walked away from my so-called life to start afresh. I am not a person who looks back or has regrets, because everything that has happened is what has made me the person I am today – a person who has no fears and who is willing to try new things.  What were you doing before you enrolled for School of Code and what made you want to sign up? I was a probation court officer for 8 years, where I dealt with the day to day running of things especially focused on breaches. Even though I was on a computer every day I knew very little about how they worked, and more importantly, why they crashed on me. I guess that pursuit is what lead me to school of Code. What are you looking to gain from studying at School of Code in the long run? I’m looking to make computers my friend and, to be honest, to make a career in coding. With these new-found skills, I’ll hopefully be able to help others, develop products and software to help others gain a good standard of living which we are all entitled to. Do you think there is a diversity issue in the tech sector? Has it affected you in any way? I do think there is a diversity issue, as when most think about tech, they think of a white male person, an introvert, not a female from a minority group. Even I had that impression and therefore thought that this sector was not for me, but then I love to challenge sterotypes. I thought why not, let’s give it a try as I have nothing to lose. Why do you think making technology accessible to all is important? This is very important as, technology is taking over the world. Within the next 10-15 years all the jobs will be in this sector. Therefore, we all need to be ready to accept tech beyond our everyday lives. 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? I think there is a bright future for people in the tech industry, I also think that all jobs will have some sort of tech that is needed. So therefore, this will need to be a diverse place where people from all sectors of life can come together. If large companies don't strive to be diverse they will be losing out on a large resource of social skills, of soft skills that diverse people can bring to the work place, putting them in positions to be global companies. 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? SoC helps and encourages people to work as a team, without the rat race to the finish. 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

John O'Nolan took some time out of his busy schedule to talk to Packt Publishing about the meteoric rise of Ghost - the stripped back blogging platform. What were the biggest issues you faced/continue to face in the development phase? Open source development is always a challenge. You’re taking a group of people from entirely different backgrounds, with widely varying skillsets, from all over the world, who’ve never met each other before - and trying to get them to work together in a way which is both functional and cohesive. Organising such a large project tends to attract an even larger group of developers, so managing that whole process is generally one of the biggest challenges which we face on a day to day basis. It’s incredibly rewarding when it all comes together and works correctly, but it takes a lot of time and attention to get right. We’ve learned a tremendous amount about this process in the last 12 months, and I’m sure we’ll learn just as much in the next 12 months. Would you recommend Kickstarter for other software devs? Are there any lessons other open-source developers could take away from it? Crowdfunding is something I’d recommend to anyone - but whether or not you use Kickstarter is a really hard one to answer, and I’ve gone back and forth on it a few times. I think these days my answer is more or less: “It depends” - as there are both advantages and drawbacks to each approach. On the plus side, Kickstarter gives a project a certain degree of credibility, puts in in front of people who might not necassarily have seen it otherwise, and gives you quite a lot of tools to manage the campaign. On the downside, they take quite a large chunk of the money you raise, you have to play by their rules, and the tools for managing the campaign are good - but not great. I think if you have an existing network or audience, independent crowdfuning might be a more compelling proposition. What are your views on the situation with Express.js, and the questions is raises overall about the OpenSource movement? The situation with Express.js was interesting, but realistically, things like this happen in Open Source all the time. It’s not a new paradigm, and to some degree it’s a bit of a storm in a teacup. I don’t think it raises any new questions about the Open Source Sofware movement - in fact in some way it points to the very strength of it. Had Express been a closed project which got sold, everyone would’ve been left high and dry. With Open Source, there is always the option to fork and create a new project if the original branch loses its way. It’s not a perfect solution (it’s often not even a good one), but in the face of the alternative: no solution at all - it’s a significant step in the direction of freedom. What's your biggest hope for the future of Ghost? Mass adoption? An increase in dialog about how we distribute our blog content? Mass adoption is always a hope, of course, but I’m definitely more passionate about quality than quantity. I would rather have 5 respected major news organisations running on Ghost than 10,000 cat blogs. I think that for journalism to continue to remain relevant it needs to continue to be free and open, both in the tools being used as well as in the organisations behind the content being created. I hope that Ghost can move the needle on independent publishing, as opposed to venture-backed click-bait. Besides a different use philosophy (just blogging!) Ghost is notable for its embrace of Node.js. Do you think more CMS systems will start to make the transition to Node.js? Yes and no. I don’t believe many (if any) existing systems are going to start transitioning to Node.js. There are far too many reasons for why it doesn’t make much sense. But I do think that we’re already starting to see a definite transition in the technologies chosen for building new platforms. Node.js is certainly towards the front of the pack, but it’s by no means the only player. There are a great deal of exciting new technologies which are lining up to power the next generation of the web, and I’m pretty excited to see where they all go. With Ghost(Pro), and fairly easy going third-party hosting, Ghost's more accessible than many open-source blogging/CMS platforms. What do you think Ghost offers over and above more packaged blog solutions? The choices right now are beautiful and closed, or clunky and open. We’re trying to combine the best of both worlds and create something really special.

What initially drew you to write your book for Packt Publishing? Trying to bundle all the CryENGINE knowledge and everything we have learned over the past decade working with CryENGINE was something we wanted to do for a long time. With a publisher like Packt we felt confident we could deliver a comprehensive CryENGINE guide. When you began writing what were your main aims? What did you want the book to teach your readers? It was really about taking the readers' CryENGINE skills to the next level. There are plenty of beginner tutorials and articles out there that focus on getting to know the engine or on building simple examples. What was really missing was a book that focused on users who already have the basic experience and know their way around CryENGINE. This is why Mastering CryENGINE covers a lot of advanced topics and contains a lot of tips and tricks useful for people using the engine in a real production environment. What did you enjoy most about the writing process and what was most rewarding about the experience of writing? Seeing the book come together and grow larger and larger over the course of many months really felt good. And of course knowing that somewhere, someone will read it one day and improve their skills with this book is something that just makes you feel good about all the work it takes to finish a book. What parts of the writing process were the most challenging? How did you overcome the The single biggest problem was cutting down the content so that it would all fit within the scope of the book. There were many more chapters, examples, and images we would have liked to add to the book. It is easy to keep on adding more content and have the book lose its focus, so we had to take a lot of care to keep the book streamlined and on topic. Why, in your opinion, is CryENGINE exciting to discover, read, and write about? CryENGINE is one of the most advanced 3D engines out there and it offers so many features and possibilities that it makes it hard to really discover everything. Even after having worked with CryENGINE for ten years I still sometimes discover new things and new best practices I didn't know about. And of course CryENGINE is always evolving. New features are being added and old features optimized. This means there are new things to discover on a regular basis that help you to build your games more efficiently. Why do you think interest in CryENGINE has continued to maintain such popularity? Today it is easier than ever to develop and publish games. You don't need to be a big company anymore to get your game published. CryENGINE gives you the tools to build amazing games in a short amount of time and release them to the public. More and more people are discovering that it is easy and fun to try to put their own games together. I think this is why CryENGINE continues to be that popular. What do you see on the horizon for CryENGINE? This year has been a busy year for Crytek and CryENGINE. A lot of features have been added. I think we will see even more features and optimization to the engine in the next months. Focus points of this development will be improvements to the ease of use of the SDK tools as well as to the pipeline and the steps necessary to actually get a release-ready game. Any tips or stories to share for aspiring/new technical authors? The beginning is always the hardest part. Once you start writing, it starts to flow. Especially with a great publisher by your side there is no need to be afraid of trying.