books - freeCodeCamp.org

What I Learned from The Pragmatic Programmer and The Clean Coder

freeCodeCamp — Wed, 24 Nov 2021 16:38:09 +0000

By Ramón Morcillo

I recently finished reading The Pragmatic Programmer 20th Anniversary Edition (2019) and The Clean Coder (2011). You'll find these books on almost every “top 10 Software Development books” list out there.

My goal was to learn, improve, and get the kind of knowledge that a teacher from mine used to say “can’t be obtained from just reading articles.”

When you are developing software, you may get stuck at a point where YouTube videos and StackOverflow answers don’t help. You end up reaching for the official docs, or the source code of that technology to find the answer.

The same thing happens when you want to understand the subject really deeply. Articles can sometimes fall short, and reading well-known books is the often best approach.

These books focus not only on how to write code, but on teaching you best practices for developing software and even useful life lessons. I’ll share some lessons I learned from them in this article.

How to Take Responsibility
Testing is Important
Teamwork Makes the Dream Work
How to Estimate
Tracer Bullet Development
How to Handle Pressure
The Importance of Refactoring
Main Differences Between These Books
Conclusion
Resources

How to Take Responsibility

As a software developer, you are responsible for the code you create. You must ensure that it not only works now but will do so in the best possible way for a long time (nothing lasts forever).

The best way to make sure the code won’t fail is by testing it – having automated tests that you run each time you write new lines to be sure everything is still working.

Take Responsibility. Responsibility is something you actively agree to. — The Pragmatic Programmer

Responsibility is not only related to coding, though. You have to take responsibility for improving yourself too and get better by scheduling time for it.

Professionals spend time caring for their profession. Presumably, you became a software developer because you are passionate about software and your desire to be a professional is motivated by that passion. — The Clean Coder

Your knowledge and experience are your most important day-to-day professional assets. — The Pragmatic Programmer

Testing is Important

The importance of testing in software development is so great that both books focus on this topic.

You have to look at tests as the first users of your code, so they are the best feedback that guides your coding.

Practice TDD Test Driven Development. How does it work? Here are its three main steps:

Choose a feature to add and write a test that will pass after implementing it. Now, all tests but the new one should pass.
Write the code required to pass it.
Refactor the code and check that all tests still pass.

This said, it is important to look at the big picture and not to miss the main goal by writing too many tests.

It is easy to become seduced by the green "tests passed" message, writing lots of code that doesn’t actually get you closer to a solution. — The Pragmatic Programmer

There are three ways of testing: First, During, and Never. First (TDD) is the best one. During is a fallback when First is not useful. And Never is often called “Test Later” but sadly in most cases Later means Never.

The need to test first forces you to think about "good design." — The Clean Coder

Having tests give you the confidence to refactor code more often because you can check to make sure that the tests still pass after you've made your changes.

Tests should be run as frequently as possible to provide maximum feedback and to ensure that the system remains continuously clean. — The Clean Coder

Use acceptance tests to define when a requirement is done collaborating with the stakeholders.

Developers take the responsibility to ensure that tests are always automated for a simple reason: cost.

Developers have should have the goal that “QA should find nothing”. You can accomplish this by implementing different kinds of tests, in different measures from unit to exploratory tests.

Teamwork Makes the Dream Work

When working on a team, you have to be a "team player", communicate frequently, keep an eye out for your teammates, and execute your responsibilities as effectively as possible.

Good communication is key to avoiding these problems. And by "good" we mean instant and frictionless. Frictionless means it’s easy and low-ceremony to ask questions, share your progress, your problems, your insights and learnings, and to stay aware of what your teammates are doing. — The Pragmatic Programmer

Teams should be small, less than 10-12 members, where everyone knows and trusts each other. This team environment is hard to achieve therefore once you get it you have to care for it changing the projects the team works on rather than the members.

As team size grows, communication paths grow at the rate of O(n^2), where n is the number of team members. On larger teams, communication begins to break down and becomes ineffective. — The Pragmatic Programmer

To form teams around projects is a foolish approach. Individuals are only on the project for a short time and therefore never learn how to deal with each other. Teams are harder to build than projects. Therefore, it is better to form persistent teams that move together from one project to the next and can take on more than one project at a time. — The Clean Coder

Furthermore, great teams will face and solve issues together where each individual will provide their best effort. They get things done as a unit. In the end, they will be known for their performance and quality of work.

Quality can come only from the individual contributions of all team members. Quality is built in, not bolted on. — The Pragmatic Programmer

A gelled team can work miracles, anticipate each other, cover for each other, support each other, and demand the best from each other. They make things happen. — The Clean Coder

Great project teams have a distinct personality. People look forward to meetings with them, because they know that they’ll see a well-prepared performance that makes everyone feel good. The documentation they produce is crisp, accurate, and consistent. — The Pragmatic Programmer

How to Estimate

This lesson, like the majority from both books, is as important in software development as in real life. The more you practice and develop it, the more intuitive will be your ability to determine the feasibility of any task.

First, I want to clarify what estimating means by sharing The Clean Coder's definition of an estimate which refers to it as a probability distribution.

An estimate is not a number. An estimate is a probability distribution, the likelihood of completion. — The Clean Coder

To help you understand it, here is a figure of the likelihood of completion of a task for the next 11 days.

One of the basics to make great estimations is to have proper knowledge of what you are estimating.

The first part of any estimation exercise is building an understanding of what’s being asked. You need to have a grasp of the scope of the domain. — The Pragmatic Programmer

Don’t estimate alone, communicate with other people to be as accurate as possible.

The most important estimation resource you have are the people around you. They can see things that you don’t. They can help you estimate your tasks more accurately than you can estimate them on your own. — The Clean Coder

A basic estimating trick that always gives good answers: ask someone who’s already done it. — The Pragmatic Programmer

When asked for an estimation choose the units that better reflect the accuracy you intend to convey. This Estimation times scale from The Pragmatic Programmer may help you.

Duration	Quote estimate in
1–15 days	Days
3–6 weeks	Weeks
8–20 weeks	Months
20+ weeks	Think hard before giving an estimate

Although Business likes to view estimates as commitments, remember that an estimate is just a guess therefore no commitment is implied.

A commitment is something you must achieve. If you commit to getting something done by a certain date, then you simply have to get it done by that date. Professionals don’t make commitments unless they know they can achieve them. Missing a commitment is an act of dishonesty only slightly less onerous than an overt lie. — The Clean Coder

Thus said, to help Business measuring requirements and making appropriate plans, you have to remove the requirement’s ambiguity before estimating. Afterwards, keep them updated about the progress.

The trick to managing lateness is early detection and transparency. Regularly measure your progress against your goal. Be as honest as you can about all dates. Do not incorporate hope into your estimates! — The Clean Coder

Do not reinvent the wheel, use well-known estimation techniques for tasks. Here I made a summary of some techniques mentioned in both books.

The more experience you have on a certain project, the better you will estimate its tasks. Therefore don’t worry if the first estimates you make are not as accurate as they could be. It is an incremental process as with every long term goal you want to achieve.

Like one of my favorite quotes states:

There is only one way to eat an elephant: a bite at a time. — Desmond Tutu

However, there is no way you can eat such cuteness:

Tracer Bullet Development

Tracer bullets are a special kind of bullet used in movies to mark the path they’ve taken as feedback for the shooter to aim better the next time. Therefore, the main goal of Tracer Bullet Development is to "shoot" new features into the project and get quick feedback to "aim" better on the next ones.

Tracer development is consistent with the idea that a project is never finished: there will always be changes required and functions to add. It is an incremental approach. — The Pragmatic Programmer

This method helps developers focus on the main features to be implemented so others can be built on.

In addition, it serves as proof the architecture is compatible and feasible by providing a functional and demonstrable skeleton to work from the beginning of the development process.

Look for the important requirements, the ones that define the system. Look for the areas where you have doubts, and where you see the biggest risks. Then prioritize your development so that these are the first areas you code. — The Pragmatic Programmer

Lastly, Tracer Bullet Development should not be confused with prototyping. The code from prototypes isn’t supposed to be part of the project, whereas the code from the tracer bullets isn’t thrown away. It works and is improved each iteration with new features.

Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired. — The Pragmatic Programmer

How to Handle Pressure

I liked this one as well, since it helps you outside software development too. Soon or later you will be under pressure, and the best tricks to handling it are to avoid it when you can, and weather it when you can’t.

The best way to stay calm under pressure is to avoid the situations that cause pressure. — The Clean Coder

You mainly avoid it by managing commitments, keeping clean, and following your disciplines.

The best way to manage commitments is by saying no to those deadlines you aren’t sure you can meet. Keeping clean basically means that you have no mess on your systems, code, and design.

The way to go fast, and to keep the deadlines at bay, is to stay clean. Professionals do not succumb to the temptation to create a mess in order to move quickly. “Quick and dirty” is an oxymoron. Dirty always means slow! — The Clean Coder

Follow disciplines you truly believe in and stick to them all the time no matter the situation. Crisis times will come, and that’s when you have to pay attention to how you behave. If you follow your disciplines it means you believe in them.

Changing your behavior and not following your disciplines would mean you don’t truly believe in your normal behavior, and you have to shift those disciplines to improve it.

If you keep your code clean during normal times but make messes in a crisis, then you don’t really believe that messes slow you down. If you pair in a crisis but don’t normally pair, then you believe pairing is more efficient than non-pairing. — The Clean Coder

Choose disciplines that you feel comfortable following in a crisis. Then follow them all the time. Following these disciplines is the best way to avoid getting into a crisis. Don’t change your behavior when the crunch comes. If your disciplines are the best way to work, then they should be followed even in the depths of a crisis.

But you can’t always avoid pressure, so you have to learn how to get through it. You weather it by staying calm, communicating, following your disciplines, and getting help.

To stay calm, don’t panic, manage your stress, and think the problem through to find the best possible outcome. Then go for it at a steady pace, like eating an elephant. Make sure you're communicating all the time with your team and superiors to let them know when you are in trouble so you can get input and guidance. This way there won’t be any unexpected surprises in the end.

Avoid creating surprises. Nothing makes people more angry and less rational than surprises. Surprises multiply the pressure by ten. — The Clean Coder

In the same way you relied on your disciplines to avoid pressure, you should also rely on them when the moment gets tough. In fact, these times you have to pay special attention to them and neither question nor abandon them.

The communication tip includes asking for help from teammates to pair, superiors, or internet sites and forums.

Don't forget to be there for others too when they are under pressure and need help.

When the heat is on, find an associate who is willing to pair program with you. You will get done faster, with fewer defects. Your pair partner will help you hold on to your disciplines and keep you from panicking. — The Clean Coder

The Importance of Refactoring

The term Refactoring is defined by Martin Fowler as a:

Disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. — Martin Fowler

Sometimes you will find code that does not feel right and should be fixed or improved. And you have to keep in mind the best moment to do so is now, when you find it.

It is inevitable: a program’s code needs to grow, evolve, and improve. To do so, you'll need to rethink some decisions, and the code will need to change. So be sure to have it covered with automated tests to guarantee that the external behavior does not change.

Rather than construction, software is more like gardening – it is more organic than concrete. You plant many things in a garden according to an initial plan and conditions. You constantly monitor the health of the garden, and make adjustments as needed. — The Pragmatic Programmer

When should you refactor the code? Here is a list of situations that qualify:

To remove code duplication.
To make some parts of the code more orthogonal.
To update code and/or documentation that's outdated.
To improve performance.

And here are Martin Fowler's tips on how to refactor without doing more harm than good:

Don’t try to refactor and add functionality at the same time.
Make sure you have good tests before you begin refactoring. Run the tests as often as possible.
Take short, deliberate steps: move a field from one class to another, split a method, rename a variable. Refactoring often involves making many localized changes that result in a larger-scale change.

The most important thing to keep in mind is that refactoring is not a certain task, it is a habit. And, as with most things in life, it is easier to do while the issues are small, as an ongoing activity while coding.

The less you refactor now the greater time you’ll have to invest to fix the problem down the road.

Refactoring as "a growth." Removing it requires invasive surgery. You can take it out while it is still small. Or, you could wait while it grows and spreads – but removing it then will be both more expensive and more dangerous. Wait even longer, and you may lose the patient entirely. — The Pragmatic Programmer

Main Differences Between These Books

I did not want this article to be a comparison – but although these books focus on similar subjects, the content and the way each is narrated are not the same.

Here are the main impressions I got from them that are not related to the content itself. These observations can help you have an idea of what to expect while reading them.

The Clean Coder speaks about the developer in a more day by day at work way. It makes references to common situations that are given in such an environment like the relationship with sales or business people, working in a team, or saying no to clients. The developer in the Pragmatic Programmer isn’t really placed in job situations. Rather, it grants an overview of the field, structuring the book on advice: topics and tips, for any situation.
The Clean Coder refers to the figure of the Software Developer as a Professional Programmer while The Pragmatic Programmer uses the totally unexpected term Pragmatic Programmer.
In general terms, The Clean Coder has a more subjective sense since it shares more personal experiences from the author. On the other hand, The Pragmatic Programmer feels more objective, focusing mostly on the advice itself.
The Pragmatic Programmer contains more code examples in different programming languages than the Clean Coder, which helps you understand the concepts discussed.

Conclusion

Keep in mind that what I've discussed here is just my own personal impressions and lessons I got from reading these two books. Each book has much more to offer, and the best thing you can do is read both yourself to form your own opinion and conclusions.

If you are interested in software development and want to get better, you should read both of them. It's worth it – they're very different and each is worth your time. And they'll bring you different knowledge and best practices for your career.

Having said that, if you still want to go the lazy way, I made this open-source project with the core sentences from each book.

Resources

The main resources are both books, which you can find easily on the internet and the project where I noted down the sentences I found most important.

I hope you enjoyed this article. You can read it too on my site along with others! If you've got any questions, suggestions, or feedback in general, don't hesitate to reach out on any of the social networks from my site.

460 Free Textbooks – Math, Science, and More [Online PDF for College and High School]

Jessica Wilkins — Thu, 09 Sep 2021 14:25:28 +0000

While you're in school, you will go through a number of textbooks and the cost can add up pretty quickly. Luckily, there are websites that offer free textbooks for high school and college students.

Here is a list of 460 free textbooks, arranged by topic. Once you find a topic that interests you, click that link and it will jump you down to a list of related textbooks.

High school Textbooks (90)

Math

Natural Sciences

Classical Novels

College TextBooks (370)

Computer Science

Engineering

Education

Math

Natural Sciences

Medicine

Humanities

Business

Law

Journalism and Communication

Machine Learning Systems Book Recommendations – Learn How to Build and Understand ML Systems

Harshit Tyagi — Fri, 07 May 2021 21:07:57 +0000

“Good friends, good books, and a sleepy conscience: this is the ideal life.”
― Mark Twain

I hope you’re reading this blog in your pjs looking forward to a rejuvenating and healthy weekend.

I have been working on multiple projects lately, from creating Machine Learing Engineering and Machine Learning Operations courses to developing end-to-end ML systems at scale. And I have realized that often times I am either revisiting a book that I’ve read or I’m referring to a book that I just skimmed through but never got the chance to really read.

This week, I want to share with you the books that I personally feel every ML enthusiast and practitioner should read to get a sense of the breadth of ideas and depth of this field.

It is a short and crisp list covering a majority of ML topics. It should be useful both for beginners getting started and intermediate-level professionals wanting to understand the intricacies of engineering successful ML systems.

So, here we go...

#1 — Hands-On Machine Learning with Scikit-Learn, Keras and TensorFlow, 2nd Edition

By Aurélien Géron

This book is simply a work of art. I highly recommend not just reading this book but also coding along with the author.

The book is divided into two parts — the first part is focused on the fundamentals of machine learning and covers all the major classic ML algorithms. It has just the right amount of mathematical explanation and Python code to actually start developing models.

The the second part focuses on neural networks and deep learning.

I have read through this complete book and have maybe read a few chapters two or three times in order to get the concepts right and do the exercises.

Reading tip for this one: Spend 2–3 days (or more if needed) with each chapter if you’re spending 2–3 hours learning actively.

#2 — Machine Learning Engineering

By Andriy Burkov

Andriy has done it again. This book explains each phase of the ML Systems Lifecycle and is a complete and concise resource for anyone who intends to build scalable ML-powered applications.

The book is a compilation of engineering challenges and best practices to make ML work in production. Andriy explains how you should look to plan a project, why projects might fail, and how to approach every step . Here are the sections in this book:

His first book, The Hundred-Page Machine Learning Book, was a great success and the same can be said about this one as well.

#3 — Practical Deep Learning for Cloud, Mobile, and Edge

By Anirudh Koul, Siddha Ganju, and Meher Kasam

The book follows the practical advice that you should learn by doing. It's a hands-on guide to building Deep Learning applications for the cloud, mobile browsers, and edge devices. I am currently reading this book and I am surprised that I didn’t stumble upon it before.

Every chapter helps you build an application end-to-end. Each application targets a subdomain of deep learning, a different serving method, or techniques to optimize experimentation using TensorFlow.

It's a must-read for people already familiar with deep learning. This book helps you dive deeper and learn by building a set of cool projects.

#4 — Building Machine Learning Pipelines

By Hannes Hapke and Catherine Nelson

After reading a number of case studies on how organizations like Spotify and Airbnb are using TF Extended to improve their ML platforms, I started learning about TFX. It can really help you optimize the development of end-to-end pipelines.

The book explains techniques to set up ML pipelines right through from data ingestion to pipeline orchestration using Airflow or Kubeflow. TFX along with TF offers tools for every step of the process.

This is an advanced-level read, and you should indulge only after you are done reading the top two recommendations.

Interesting Read of the Week

This is a slightly unusual recommendation compared to what I usually write about. But I couldn’t resist sharing it with you because of the sheer quality of the work here.

Do you understand how an internal combustion engine works? How all of these parts come together to power your vehicles and machines? Well, I have come across the best possible explanation of the functionality of all the basic engine parts.

Read the article: Internal Combustion Engine by Bartosz Ciechanowski

The beautifully designed, 360 degree, in-action illustrations along with the explanation not only help you understand combustion engines, but for my part it definitely inspired me to work harder on my art.

This made me question whether our education system is doing enough to inspire us or are they just getting away with “teaching” us.

Thanks for reading!

That’s it for this week. I don’t want to bog you down with a plethora of random ML books. Feel free to reach out if you have any thoughts, recommendations, or questions.

If this tutorial was helpful, you should check out my data science and machine learning courses on Wiplane Academy. They are comprehensive yet compact and helps you build a solid foundation of work to showcase.

How to Write Your First Technical Book: Tools, Techniques, and Resources for First-time Developer Authors

freeCodeCamp — Tue, 22 Sep 2020 19:35:55 +0000

By Shubham Chadokar

Recently, I wrote my first technical book – yes, I finally finished it. ?
This project was on my list for a long time. And now that I've finally completed it, I'd like to share my experience with everyone.

In this post, I tried to document my complete journey of writing the book. I discuss everything motivation and hurdles to tools, techniques and resources.

My book focuses on the Hyperledger Composer Blockchain tool. It is completely free and right now is only available in PDF format.

All these points are equally helpful for technical blog writing. So let's get started and dive into what I learned.

Motivation

I have been writing technical articles and tutorials since late 2018. By now I am quite comfortable with the process of writing an article or a tutorial. I understand how to approach the article and which tools I should use.

But when it comes to book writing – and especially a technical book – the arena is quite different.

My motivation was curiosity. I wondered how authors write books. What is their thought process? What tools do they use? And of course, how does it feel to write a book? ?

I am a Software Engineer and I have been working on Blockchain since 2018. I have learned about different blockchains like Ethereum and Hyperledger Fabric. I have also used many tools like truffle, remix and hyperledger composer.

There were a few different things I wanted to write about, like Ethereum or Hyperledger Fabric.

But since it was my first book, these topics were not ideal for me. They would've required a lot more time and effort than I could give. So, I picked a simple one: Hyperledger Composer.

First Hurdle

Before getting started, I wondered which tool or editor I should use to write the book.

Should I write in MS Word, Google Docs, or use something else?
The major issue was how to format code snippets correctly. These editors are not designed for technical writing.

There are different work arounds to add code, but it would require additional formatting.

I read lots of articles about what good tools are available for technical book writing. I tried many of them, but I wasn't happy with any of them. I wasted a lot of time finding the perfect tool.

In the end, I realized that editors only ease the writing process and make managing the book simpler. But what really matters is the content. So, I stopped searching for the perfect editor and went to the basics.

The basics: VS Code

I used my favourite code editor to write the book. Yes, VS Code ?.

After spending days searching around on the Internet, not a single article suggested that you need any specific tool or editor to write a technical book. VS Code or Atom would be more than enough.

I wrote the whole book in VS Code in my favourite markdown format. To make my writing easier, I used a couple of markdown plugins like Markdown All in One and Markdown Preview Enhanced.

The first plugin helps you write markdown while the second helps in preview mode. It shows how the markdown will look and behave after converting it into HTML or other formats.

Markdown All in One also has a preview mode, but Markdown Preview Enhanced has multiple themes and options to export the markdown file in HTML, PDF, and other readable formats like epub or Mobi.

Just a heads up – those other formats require that you install Pandoc on your machine.

I am a Windows User. For Mac Users, I found there are many great editors available like bear, ulysses and many others.

Recently, I discovered that there are many markdown editors available on Windows and MacOS which you can use for book writing. Check out Notion, Typora, iA Writer, and SimpleNote.

Bottom line Don't waste too much time finding the perfect editor. Just start writing in your editor of choice. With time you'll figure it out.

Second Hurdle

Then I started asking myself, from where should I start writing? How should I write? How should I approach it?

In short, I wanted to know how exactly I should write this book so that the reader would get the most out of it.

These questions made me scratch my head a lot. In the beginning, I changed my approach 4 or 5 times.

At this point, I suggest spending some time to really ponder your approach. Because once you're in the middle of the book, it is not going to be an easy task to change it.

Ask the questions

I asked myself these questions about the book and noted my thoughts down.

Who is my target audience? Are they beginner, intermediate, or expert?
Do they need some prior knowledge of the subject?
How should I organize the book?
How should I name the files or chapters so it's easy to find each topic?
How should I track my progress?
How should I maintain the versions of the chapters and drafts of the book? There will be a number of occasions that last edit was actually much better than the current version.

These are a few basic questions which I asked, and they were helpful.

My approach

I'll now describe the approach I took to writing this book.

Create a todo list

First, I created a to-do list. In this list, I noted down all the main points, topics, sub-topics, references, preface, cover, title and so on.

I pretty much added all the thoughts that came to mind about the book.

I would suggest creating 2 todo lists: one on paper and the same as a soft copy.

First, note down all the points on paper. Once you note down everything, read it 2-3 times. Then whatever new ideas pop into your head, note them down.

For example, if you think about how you're going to explain a particular topic, note it down. It will make your work much easier. Then when you start writing about that topic, you can refer to these notes.

Once you have a todo list on paper, create a soft copy and save all the points in chronological order.

This is what my todo list used to look like:

Tasks

[x] Index
[x] Cover
[x] Title
[x] Subtitle
[x] Preface
[x] What is Blockchain and Hyperledger Fabric?
[x] Introduction to Hyperledger Composer
[x] Environment Requirements and Setup
- [x] Azure
- [x] AWS
- [x] GCP
[x] Project Objective
[x] Project Setup in Composer
[x] Model File
- [x] Definition
- [x] Modeling Language
- [x] project code
[x] Script File
- [x] Definition
- [x] syntax
- [x] project code
[x] Query File
- [x] Definition
- [x] Query Language
- [x] project code
[x] ACL File
- [x] Definition
- [x] syntax
- [x] project code
[x] Deployment in Composer Playground
[x] Testing in Composer Playground
[x] Export the .bna
[x] Composer Rest Server
[x] Frontend
[x] Conclusion
[x] References
[x] About Me
[x] Grammar Check 1
[x] Grammar Check 2
[x] Read the draft
[x] Read the final draft
[x] PDF format
[x] Add page no. to PDF
[x] New chapter starts from the new page
[x] Thank You Note
[x] License
[x] End cover

I used markdown format for my todo list. You can use whatever format is easiest for you.

Start Small but Do Start

Keep in mind that you don't need to write about each topic in order. There might be many topics which depend on previous topics, but others won't.

Also, you don't have to finish writing about the topic all at once either. Whatever topics you are feeling comfortable with, start there.

Your goal should be to start the book. Aim to write 10-20% of your book within a couple of weeks. Once you start, it will keep reminding you that you have to complete the book. In time you'll realize that this turns into a great motivator.

If there is a topic you don't know as much about, don't worry. Don't hesitate to get help from the Internet. Read how other people explained it. Take inspiration and then write about it in your way.

And remember – If you use any content from other people's work, make sure you inform them, cite it properly in your text, and list their work as a reference at the end.

Consider this as a professional courtesy. -- John Wick ?

Chronological Order

It took me a while to understand the importance of having a file naming convention.

At first I started following a Chapter 1, Chapter 2 naming convention for each topic. It turned out to be a terrible idea.

The problem with this naming scheme is that you have to maintain a separate file where you explain what is in the file. Or you have to open each file to see what it contains.

Another problem is that if you add a new chapter in between then you have to rename all the following chapters.

There are two conventions I found helpful, but each has its disadvantages.

One option is to use chapternumber-topic: Name the file as a chapter number followed by the topic of the chapter. Like this 10-Introduction-of-Blockchain.

Name the chapter number in 2 digits. This will help you add sub-sections to the same chapter in different files. Like this 11-History-of-Blockchain.

Another benefit of this naming convention is it will show all the files in the order of your book chapters.

Disadvantage: Adding new chapter in between requires that you rename all the following chapters.

The second option is to use filename as topic: Name all the files as the topic name. This will give you the freedom to write topics in random order. And you can maintain the order of the book in your todo list.

Disadvantage: All the files will be arranged in alphabetical order. After 10-15 files it will be difficult to track all the files, and it'll be harder to put them together in a draft.

In the end, I followed the second method. It worked alright for me.

To create a draft, I created a Node.js script. In this script, I entered all the topics in an array. Then I created a draft file and appended all the topics in it. Of course by reading them first ?. A few perks of being a Software Engineer ?.

This script was a saviour when I was editing. Many times I updated the topics or pictures within them. I fixed grammatical mistakes. Here Grammarly really saved me...but not completely as I was using the free version. ?

Chronicle of the book journey

Writing a book is not a sprint, it is a marathon. Always save your work when you complete a topic or are done for the day.

The next day, you might get a new idea for the same topic which you already completed. You might spend an hour on it, but it doesn't look good. In this case, UNDO is great but it also has limitations (and its limits vary from editor to editor). Do not test its limits too much.

Instead of relying on the editor or making duplicate copies, I used Git for version control. Don't think that git can only be used for managing your code. It is a versitile tool and its applications are only limited by your imagination.

For the readers who don't know about git:

Git is a distributed version control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. --Wikipedia

You don't have to learn everything about git to use it for writing. The basic commands like init, add, commit, logs and checkout are more than enough for you to maintain your versions and keep your text accessible and safe.

There are many Git code hosting platforms available, like GitHub, GitLab and others. To host your book on one of these platforms, you can follow the below steps:

Create an account. My personal choice is GitHub.
Create a private repository with default choices. You can change its visibility to public in the future.
Follow the instructions provided once the repository is created. Basically, in this step, you're connecting your local Git to your hosted repository.
Learn 2 more commands, push and pull. Use push to push the local changes to the cloud repo and use pull to get the content from the cloud.

After this, whenever you make any changes, just add, commit and push. Simple, isn't it? ?

After a couple of commits, you will feel comfortable with git.

Check out this amazing article to learn more: Learn Git and Version Control in an Hour

The tools and resources I used

I used many tools and resources while writing, editing, formatting and designing the book.

Writing

For writing, I used the VS Code editor with a couple of markdown plugins, as I've discussed above.

For emojis, I used copy and paste emojis.

Editing

For correcting grammatical mistakes I used the free version of Grammarly. In the free version, it corrects all the basic mistakes like incorrect or missing articles, prepositions, commas, and so on.

I used the online pdf editor to add page numbers to the book.

Formatting

I used the Markdown in Preview plugin in VS Code to generate the PDF format. I used the default Git markdown formatting. You can change the formatting in the settings.

Page breaks in the PDF

As I was writing in markdown format, the PDF output was inconsistent. For example, it starts a new topic from the last page instead of from a new page.

To fix this, I used the page break html code at the end of each topic.

<div style="page-break-after:always;">div>

This will make the content that follows it start on a new page.
You can also add the end of the page-sequence like ***** this.

<div style="page-break-after:always; display:block; text-align:center; border:none">*****div>

About Me Page

In the About Me section of my book, I divided the content into two columns: a brief about me and a profile picture.

It took me a while to realize the full capabilities of the markdown format. We can add plain html code in it. Here's what my "about me" page says:

<div >
  <img align="right" style="padding-left:65px" src="../images/profilepic.JPEG" width="400px" height="450px" />
div>

Hello, I am **_Shubham Kumar Chadokar_**.

I am a Software Engineer and in my short career of almost 4 years, I've had the opportunity to work on Blockchain, Nodejs, Golang, and Docker.

I've learned about other tech as well, but these are my primary focus. I love to write articles and tutorials on new tech by following a hands-on approach. This is my first book.

Front end development isn't my specialty, and that's why I didn't include it in the book.

If you have any queries or questions, please feel free to drop me an email.

:e-mail: [hello@schadokar.dev](hello@schadokar.dev)
:globe_with_meridians: [schadokar.dev](https://schadokar.dev)
<img src="https://github.githubassets.com/images/icons/emoji/octocat.png" style="width:20px;" />[github.com/schadokar](https://github.com/schadokar)

For octacat, I used the img tag.

It looks like this.

Thank You Page

I added a thank you page to express my gratitude to the Hyperledger Composer Community for their work. I tried to add the content in the middle of the page.

<div style="padding-top:40%; text-align: center; font-size:35px;">
Thank You <img src="https://emojipedia-us.s3.dualstack.us-west-1.amazonaws.com/thumbs/240/microsoft/209/person-with-folded-hands_1f64f.png" style="width:40px" />
div>
<div style="text-align: center; font-size:25px;">
I especially want to thanks the entire
<a href="https://github.com/hyperledger/composer/graphs/contributors">Hyperledger Composer Communitya> for creating such
an amazing tool. Many developers entered into the blockchain domain because of the simplicity of the composer. <br />
It is unfortunate that it is deprecated but it sets a great example of easy automation,
wrapping a complex Hyperledger Fabric into the easy to use Hyperledger Composer.
div>

It looks like this.

Book Title and Sub-title

The book title should make the contents of the book clear in a few words or one short sentence.

While you're writing the book, note down all the keywords you use. This will help you to come up with a great title. You want to capture the essence of the book and let readers know, for example, whether it's theoretical or more hands-on.

A sub-title should give readers more detail about what they will get from this book or what they are going to learn.

A one sentence sub-title is ideal, and shouldn't be any longer than two sentences. Don't overdo it – let readers read the book. The idea is to give readers a taste of the complete book in one sentence but still not to tell anything ?.

My book title is Playtime with Hyperledger Composer and sub-title is Create a supply chain management project in Blockchain using Hyperledger Composer.

When you start writing your book, don't spend much time on the book title. When you finish writing, you'll be in a much better position to decide the book title. Everything is written, you know what it is all about, and what others will get from it.

In my case, I changed the book title and book cover at the last moment before publishing it. Before that, it was so boring ?.

Designing the Book Cover

You might have heard the idiom Don't judge a book by its cover.
But the harsh reality is, a book's cover is very important. It is the face of the book.

Try to keep it simple and informative. Don't overdo it. A simple title and a short subtitle with an image or two is more than enough.

I started designing the book cover by taking references from other books, and trying to edit them in Paint. The result was a complete disaster, and I couldn't think of anything good.

Then I realized that designing is not my cup of tea. I decided to hire a freelancer for this, so I checked out freelancing sites like UpWork and Fiverr.

Then, I found Canva. It's such a great tool. Amazing! ? ? ? ?

Canva is a graphic design platform that allows users to create social media graphics, presentations, posters and other visual content. It is available on web and mobile and integrates millions of images, fonts, templates and illustrations. Wikipedia

I used one of the templates from the canva book cover section and created my book cover. Not bad, right? ?

License

I wrote this book out of curiosity and for fun. So, I wanted it to be free, and open-source, but I didn't want others to monetize it. Without a license, there are no restrictions.

I searched for a while and found a great answer on StackOverflow regarding free licenses, Creative Commons Licenses.

Creative Commons is a nonprofit organization that helps overcome legal obstacles to the sharing of knowledge and creativity to address the world’s pressing challenges.

They have provided a form with a couple of questions related to what kind of license you want. Fill out the form and voilà ?, your license is ready. Copy and paste it or use the embedded link.

Publishing your book

There are many options you can choose from to publish your book. You can approach a publishing house and send in your draft. If they want to publish you can go ahead and secure a deal.

After this, the publishing house takes care of other processes like formatting, editing your book, creating an attractive book cover, all the licensing, the publishing process, and most importantly marketing.

In short, if you want to monetize your book and you're expecting a good amount, then a publishing house is the best option available.

Another option is self-publishing. Yes, we can self-publish our own books. Amazon's Kindle Direct Publishing provides a great platform for this. It is free and it publishes the book worldwide.

You'll get 70% of the profits for each sale. The kdp take cares of all the publishing process. You just have to write the book, upload it and format it.

You simply enter the price you want to charge, along with some basic info about the book and and yourself. You can follow their tutorials for more info – they have done a great job.

But I wanted to keep my book free and didn't have the patience for the above processes. So, I self-published it without using any third party.

I just converted the book to PDF format and saved it in an AWS S3 Bucket so that anyone can download it. Then I hosted the book on my website. Simple. ?

Once you complete your masterpiece, it is time to show it to the world.
If you haven't teamed up with a publisher or even if you did, you have to spread the word.

These are the few platforms I used, but don't limit yourself.

LinkedIn is a professional platform and many developers are on it, no matter their specialty in the tech world. You'll also find people of every profession, you name it.

Share your work with them, ask for feedback. 90% of the time you'll get a reply. I shared my work with Dan Selmon, one of the Hyperledger Composer contributors, as well as Srinivas Mahankali, who wrote many books on Blockchain.

They were both very helpful and gave their honest feedback. I am thankful to Dan, who even offered to share the book among his network on LinkedIn and Twitter. ?

Reddit is a community hub. You will find many active communities on various subjects here. You just have to join the community that's relevant to your work and share it there.

You'll find a lot of active members on Reddit, in these groups, and they are not shy to share their opinion. If there is a room for improvement, some of them might offer to help.

But before sharing, DO READ THE GUIDELINES. If you violate any of them, they will remove your post.

Twitter

Twitter is not just a social platform where people share their opinions. So don't underestimate it.

If you like facts and figures, here you go: there are 1.3+ billion accounts on Twitter, 330 million monthly active users, 152 million daily active users and 500 million tweets per day. This is huge.

You just have to craft your message and select the right keywords within the 280 characters limit and you can potentially reach a large audience.

Blogs

Do some research and figure out which publications or digital magazines publish articles in your book's category. Share your book summary and details with them.

Ask them if they can write an article about your book. Or you can write an article about your book and share the draft with those publications.

There are also many other platforms you can try – just do a bit of digging.

Conclusion

This was my first experience writing a book. It took some time but it was worth it. Now, I have another badge on my portfolio. ?

I learned a lot from this experience. This article serves as documentation of all my learning for anyone who wants to write their first book or their next book.

Below is the final list of tools I've used so far.
Any suggestions for others are most welcome.

Thank you for reading and don't forget to share your first book with me. ?

Final List of Tools I used

Editor: Visual Studio Code with 2 Markdown plugins
Versioning Tool:Git and GitHub
Emojis: Copy and Paste emojis
Grammar Check: Grammarly
License: Creative Commons Licenses
Cover Design: Canva
PDF page number: online pdf editor
eBook storage: AWS S3 bucket.
Book Hosting: On my blog

Thanks for Reading

If you have any feedback or suggestions to help me improve this article please connect with me on twitter or email me.

Read my other articles
Subscribe to My Newsletter

Cover photo by Thought Catalog on Unsplash

Best Computer Programming Books to Help You Learn to Code

freeCodeCamp — Tue, 28 Jan 2020 01:11:00 +0000

Here are some book recommendations covering everything from general programming knowledge to language-specific information. Happy reading!

General

Automate the Boring Stuff With Python by Al Sweigart

http://automatetheboringstuff.com/
ISBN-13: 978-1593275990

Structure and Interpretation of Computer Programs by Harold Abelson, Gerald Jay Sussman, and Julie Sussman

https://mitpress.mit.edu/sicp/
ISBN-13: 978-0262510875

Clean Code: A Handbook of Agile Software Crafstmanship by Robert C. Martin

Amazon Smile
ISBN-13: 978-0132350884

CODE: The Hidden Language of Computer Hardware and Software by Charles Petzold

Amazon Smile
ISBN-13: 978-0735611313

Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability by Steve Krug

Amazon Smile
ISBN-13: 978-0321965516

Programming Pearls (2nd Edition) by Jon Bentley

Amazon Smile
ISBN-13: 978-0201657883

Structure and Interpretation of Computer Programs

https://mitpress.mit.edu/sicp/
ISBN-13: 978-0262510875

The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas

Amazon Smile
ISBN-13: 978-0201616224

The Self-Taught Programmer: The Definitive Guide to Programming Professionally by Cory Althoff

Amazon Smile
ISBN-13: 978-1520288178

You Don’t Know JS (book series) by Kyle Simpson

https://github.com/getify/You-Dont-Know-JS
ISBN-13: 9781491924464

Soft Skills: The software developer’s life manual - John Sonmez

Amazon Smile
ISBN-13: 9781617292392

Algorithms

Introduction to Algorithms, 3rd Edition (MIT Press) by Thomas H. Cormen and Charles E. Leiserson

Amazon Smile
ISBN-13: 978-0262033848

Cracking the Coding Interview: 150 Programming Questions and Solutions by Gayle Laakmann McDowell

Amazon Smile
ISBN-13: 978-0984782802

C-lang

The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie

Amazon Smile
ISBN-13: 978-0131103628

A Book on C: Programming in C

Amazon
ISBN-13: 978-0201183993

Coding Interview

Cracking the Coding Interview: 150 Programming Questions and Solutions

Amazon Smile
ISBN-13: 978-0984782802

Programming Interviews Exposed: Secrets to Landing Your Next Job, 2nd Edition

Wiley
ISBN: 978-0-470-12167-2

Java

Head First Java by Kathy Sierra and Bert Bates

Amazon Smile
ISBN-13: 978-0596009205

Effective Java by Joshua Bloch

Amazon Smile
ISBN-13: 978-0134685991

JavaScript

You Don’t Know JS (book series)

https://github.com/getify/You-Dont-Know-JS
ISBN-13: 9781491924464

Eloquent JavaScript: A Modern Introduction to Programming by Marijn Haverbeke

Read it online here
Amazon Smile -ISBN-13: 978-1593275846

JavaScript: The Good Parts

Amazon Smile
ISBN-13: 978-0596517748

JavaScript and JQuery: Interactive Front-End Web Development

Amazon Smile
ISBN-13: 978-1118531648

Python

Automate the Boring Stuff With Python

http://automatetheboringstuff.com/
ISBN-13: 978-1593275990

Core Python Applications Programming (3rd Edition) by Wesley J Chun

Amazon Smile
ISBN-13: 978-0132678209

Soft Skills

Soft Skills: The software developer’s life manual

Amazon Smile
ISBN-13: 9781617292392

Other

*Hacking: Ultimate Hacking Guide: Hacking For Beginners And Tor Browser

https://www.amazon.in/dp/B075CX7T6G/ref=cm_sw_r_cp_awdbt1-7ESBbZ43CCBM
(ISBN 1976112524).

Code: The Hidden Language of Computer Hardware and Software (Developer Best Practices)

Amazon Smile
ISBN-13: 978-0735611313

Data Structures And Algorithms Made Easy

Amazon Smile
ISBN-13: 978-8193245279

Think Python: How to Think Like a Computer Scientist

Amazon Smile
ISBN-13: 978-1491939369

Python Crash Course: A Hands-On, Project-Based Introduction to Programming

Amazon Smile
ISBN-13: 978-1593276034

Computer Science Distilled: Learn the art of solving computaitonal problems by Wladston Ferreira Filho

Amazon Smile
ISBN-13: 978-0-9773160-2-5

Algorithms Unlocked by Thomas H. Cormen

Amazon Smile
ISBN-13: 978-0262518802

Violent Python: A Cookbook for Hackers, Forensic Analysts, Penetration Testers and Security Engineers

Amazon Smile
ISBN-13: 978-1597499576

The Shellcoder’s Handbook: Discovering and Exploiting Security Holes

Amazon Smile
ISBN-13: 978-0470080238

Head First C: A Brain-Friendly Guide

Amazon Smile
ISBN-13: 978-1449399917

Practical Object-Oriented Design in Ruby

Amazon Smile
ISBN-13: 978-0321721334

Thinking in C++ by Bruce Eckel

Amazon Smile
ISBN-13: 978-0139177095

Operating System Concepts

Amazon Smile
ISBN-13: 978-1118063330

Computer Networking: A Top-Down Approach (7th Edition) by Kurose and Ross

Amazon Smile
ISBN-13: 978-0133594140

Competitive Programming 3: The New Lower Bound of Programming Contests

Amazon Smile
ISBN-13: 978-5800083125

Dynamic Programming for Coding Interviews: A Bottom-Up approach to problem solving

Amazon Smile
ISBN-13: 978-1946556691

GATE 2019 Computer Science and Information Technology

Amazon Smile
ISBN-13: 978-1946581785

The Art of Computer Programming by Donald E. Knuth

https://www-cs-faculty.stanford.edu/~knuth/taocp.html
ISBN-13: 978-0321751041

Facts and Fallacies of Software Engineering

Amazon Smile
ISBN-13: 978-0321117427

The Mythical Man-Month: Essays on Software Engineering

Amazon Smile
ISBN-13: 978-0201835953

This list was compiled from multiple suggestion threads on Reddit and Stackoverflow.

Please feel free to add more that you have found useful!

Other programming book recommendations:

What I Learned from Reading "The Pragmatic Programmer"

freeCodeCamp — Wed, 22 Jan 2020 16:28:10 +0000

By Pramono Winata

In short: old but gold.

Published in 1999, The Pragmatic Programmer is a book about how to become a Pragmatic Programmer. Which really means a ‘Good Programmer’.

Yes, it was published about 20 years ago. But this book still provides many insights that are very relevant to programmers or software engineers, as some people might call them these days.

You might have heard about this book before and questioned what actually it's actually about. Well, today I will share with you some of the interesting things I learned while reading the book.

There is more to being a programmer than technical skills

_Photo by [Unsplash](https://unsplash.com/@alexkixa?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Alexandre Debiève / The cat ate my source code

_Photo by [Unsplash](https://unsplash.com/@chen93?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Chen Zhao / It’s all about a broken window

_Photo by [Unsplash](https://unsplash.com/@pawel_czerwinski?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Paweł Czerwiński / Take the initiative, be the catalyst

_Photo by [Unsplash](https://unsplash.com/@bradencollum?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Braden Collum / More so, this book also teaches us about basic fundamentals that we often forget as programmers.

Sometimes, the more we delve deeper and deeper into our work, the more often we forgot about the basic things that we learned a long time ago.

Busy chasing features and new tech improvements, we often forget that there are actually a lot more things that we need to pay attention to beforehand before going deeper.

Clean code

_Photo by [Unsplash](https://unsplash.com/@4themorningshoot?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Oliver Hale / Find the correct tools

_Photo by [Unsplash](https://unsplash.com/@carlevarino?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Cesar Carlevarino Aragon / Don’t program by coincidence

This is one very important point noted in the book. In all of our programming journeys, there have likely been times when we were just coding blindly and unexpectedly… and somehow it just worked.

You probably weren't sure what you were actually doing, so you kept adding more and more code and it still worked. That is, until one day when there was an issue and you tried to remove some chunk of code and it completely broke everything. And you were not sure which piece caused it.

Relying on unknowns is very dangerous. When you are not sure what the code is supposed to do, try to simplify it and make sure that the code is reliable in its own right, not just reliable by chance.

Rely only on things you are sure of. Don’t program by coincidence.

Unit test

Testing is a hot topic these days. And yes, it was also an important topic 20 years ago (and it will always be).

But sometimes people forget about unit tests these days. They might have just finished their code and they assumed everything was okay...until the code ended up broken in production because of edge cases.

In order to maintain stability and refactor safely, we always need to keep our code protected by writing unit tests. And it’s never enough if your tests only cover the happy path. Perform ruthless testing on your code, and remember that your code is not finished until you've covered every available test.

Unit testing will help you be confident that your piece of code is truly done.

Taking ownership

There's one last thing I want to talk about. As we know, programmers like to leave ‘legacies’ behind, in the form of code. And yes, most of the time it’s bad.

Being a programmer, we ought to take pride in our own work. We should be proud of the responsibility we've been given and the piece of code we have been working on.

When we are finally able to take pride in our code and own it, we will be able to leave a good legacy behind. And people will see our code as a signature. When they see our code, they'll know that it will be solid and well-written, by a professional.

Finishing up

There are even more topics covered in this book that I haven’t discussed here, such as Requirements and Teamwork. If you are interested in exploring these topics, you should try to find and read the book!

Just a note, however: as much as I liked the book, some stuff just didn't seem relate-able, looking at how old the book is (20 years old). It talks about old languages such as Prolog, and speaks about OOP like it’s a really new concept - so these oddities just don't seem right.

But it can’t be blamed since it's already a couple decades old.

Aside from that most of the stuff covered in the book is still quite relevant to the current age of Programming, like those topics I covered above.

If I was trying to sum everything up in this book, I'd say it basically covers everything I have ever read on the Web about becoming a better engineer.

Thanks for reading my article about The Pragmatic Programmer! Hopefully it has given you some insight into your journey as a Programmer or Software Engineer. And grab yourself a copy of the book if you are interested in learning more.

P.S. I wrote this article on my own, without any means of advertising or marketing from a third party. The cover photo was taken from amazon's site.

What's on my software engineering bookshelf

freeCodeCamp — Sun, 27 Oct 2019 21:29:39 +0000

By Luca Florio

Keeping up to date and constantly improving is part of the job of a software engineer.

There are lots of ways to study new things on the internet like MOOCs, tutorials, and articles. However, sometimes a physical book is the best choice, especially when it is a "reference" that provides knowledge that will last for the years to come. We can put it on our bookshelf and go through it every time we feel it is necessary.

This is a list of reference books I keep on my software engineering bookshelf. I hope it can be a source of inspiration for everyone looking for something interesting to read! ?

What I have on my bookshelf

Design Patterns: Elements of Reusable Object-Oriented Software

This is a classic.

In this book, the so-called "Gang of Four" present the 23 design patterns that drove the Object-Oriented world for decades. New patterns have been created since then, but the ones in the book are considered the foundations of all other patterns.

It is not an easy read, but you should have a look at it just to understand where to find what you need on every occasion. Keep it on your desk, and go through it when you are building something and have the feeling, "What I'm doing sounds familiar." You will probably discover that you are trying to implement a design pattern already described in this book.

Clean Code: A Handbook of Agile Software Craftsmanship

I read this book many years ago, but it has stuck with me since then.

This is a great source of best practices to produce clean, readable code and avoid code smells. The book is focused mainly on Java/OOP, but lots of advice can be applied to every language or programming paradigm.

Writing maintainable and readable code is not a luxury -- it is something every good software engineer should aspire to. This book will provide you with the knowledge to make that happen.

Uncle Bob can be a little extreme sometimes, and I don't agree with him on all of the presented techniques. My suggestion: read it, and take with you only the things you feel are right. In any case, it is a book worth reading.

Learn You a Haskell for Great Good!: A Beginner's Guide

This is a book on the Haskell programming language, so why buy it and keep it as a reference? My reasons are:

It is a very well written and easy-to-read book on a not-so-easy topic like functional programming
It gives you the foundation of functional thinking, not just Haskell syntax
Haskell is a very elegant language and I like it

This is the book that introduced me to functional programming. Right now I program mainly in Scala, but the transition has been a lot easier after learning the basics of Haskell.

Functional programming is not easy, but it will open your mind. It can be very theoretical, and put it into practice using Haskell will help a lot.

There are also very nice drawings in the book, so you have no excuse not to flip through it. ?

Category Theory for Programmers

This book covers Category theory, which is the foundation of the functional programming paradigm.

The topic is quite complex for non-mathematicians, but the author has put great effort into making it understandable for developers. I admit that I had some difficulties reading it, but I would like to go through it again.

This book is not required to become a great functional programmer. Read it if you like challenges and want to go deeper on the theoretical foundations of functional programming.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

This is my favourite, maybe because I love distributed systems! :-D

In this book, Martin Kleppmann describes all the various aspects of distributed systems, from serialisation to consistency models and consensus, passing through the various database engines. He also explores new trendings regarding data-driven applications.

In a world of cloud-native microservices-based applications, it is fundamental to know the various aspects of a distributed system. The knowledge provided by this book is not tied to a specific technology and will be valuable your entire career in software engineering.

Release It!: Design and Deploy Production-Ready Software

I'm reading this one now.

Are we finished once our software is sent to production? Nope, that is just the beginning!

This book highlights what can go wrong after the software is put in production and has to face real users. It describes anti-patterns that can undermine the stability of our software, as well as solutions to such problems.

What I like the most about this book is that every chapter starts with an example taken from real life. Then the author analyses the problems that caused the software to fail in production. I think learning from concrete examples is a very effective approach.

Introduction to Algorithms

What can I say about this book? Just buy it and keep it on your desk.

If you are a software engineer, there is a high chance you had to study data structures and algorithms. It is not always easy to deal with complexity or to choose the right data structure.

When doubts arise, open this book and you will find what you need for.

For most people (including me) this is a very hard read. I usually just read what I need to know at that moment, and keep the book in sight on my desk.

Hyperfocus: How to Manage Your Attention in a World of Distraction

This is not a technical book, but it is in the set of readings that changed my life in better.

Our work as software engineers consists of solving problems with our minds. To be effective in this task, we need the ability to completely focus on the problem we are solving.

Here you can find lots of suggestions and techniques to maximise the time you can focus on a task. The author discusses also the importance of letting your mind wander when you need to be more creative.

Mastering how to use your attention is something that will improve not only your performance at work, but also every other aspect of your life.

What I will add to my bookshelf

The Pragmatic Programmer

This is one of the most famous books in software development.

The suggestions and techniques presented in this book influenced the careers of many developers and engineers for the better. The book was been published in 1999, but it is now available as new and updated 20th-anniversary edition.

You can't miss this. :-)

Refactoring: Improving the Design of Existing Code

It is hard to always deliver high-quality code. Deadlines, urgency, a bad day all affect the quality of your work.

That's why refactoring is so important. If we couldn't provide quality the first time, we can improve it later for better maintainability. Martin Fowler (one of my idols in the world of software development) describes the best techniques for an effective refactoring.

There will be always space on my bookshelf for books that help me write better code.

Conclusion

This is my list of must-have books on software engineering. It is by no means a comprehensive list of "important" books in this field, and I'm sure I will add more and more books in the years to come.

Hopefully I gave you some nice tips on the next book you should read. ?

See you!?

Why is so much enterprise documentation so awful?

David Clinton — Thu, 15 Aug 2019 13:30:00 +0000

I spend a very large portion of my professional workday reading through technology documentation. Perhaps “reading through” isn’t quite the right way to describe it. At this point, it’s more like quickly scanning menus, FAQs, and paragraph headings for clues to where I can find the exact piece of information I’m after.

With some exceptions, this tends to be the case whether I’m just looking for a quick confirmation of the right command line syntax or whether I’m trying to get my mind around a whole new technology.

Web-based Technology Documentation: The art of underperformance

Now, I have no complaints with the people who provide detailed syntax guides and main pages — why should they reformat their entire document to highlight some obscure detail for which I may someday come searching?

But when I’m trying to introduce myself to a complicated software package — to figure out its purpose and primary use-case — then it’s reasonable for me to expect a relatively predictable and comfortable route to my goal. Instead, I often encounter a project home page with links to multiple targets with names like “Getting Started,” “How to use…?” “Documentation” and, buried deeply under a few menu layers, “Quick Start Guide.”

Often, the pages I’m sent to will be incomplete, apparently the victims of changed minds and budget overruns. Others will cover outdated versions of the software that might easily have a feature set that’s significantly different than the latest version. Worse: the features might actually still exist but, between then and now, they’ve changed names and even icons.

Even if we ignore the quality of the writing — something that can be remarkably difficult and costly to control — and the intelligibility of individual documents, there often seem to be significant version control and project management problems.

I can usually guess what happened: some customers complained that they couldn’t figure out how to use the software, so management — unable to properly assess the current state of the documentation on their own — ordered the creation of a complete new set from scratch. The project starts, but about half way through, the key contributor either leaves the company or is distracted by other deadlines and demands.

And there it sits until a few more customers complain that they, too, can’t figure out how to use the software. Rinse. Repeat.

Is poor documentation always evil? Absolutely not. I’m often amazed at just how much some open source projects manage to accomplish considering the limited resources they’re usually working with. And, in any case, as long as people (like me) aren’t volunteering to help out, we have no right to grumble.

Is all documentation evil? Nope. While you could argue that there’s way too much of it, Amazon’s AWS maintains a magnificent documentation resource that’s well-written, well-designed, and so well organized across the system that finding elements within any given page is predictable and fast. AWS isn’t the only success story out there, but it’s not exactly part of an overcrowded field, either.

Technology Books: the art of overperformance

At the other end of the documentation continuum lie books. Remember those? While I may not have purchased a tech book for years, many thousands of other people do it all the time. In fact, at least in the short term, the technology publishing industry seems remarkably healthy.

The better traditional publishers will subject a book proposal to very close analysis before concluding that the idea makes sense and that there are enough readers interested to make it worthwhile. Once the writing begins, they’ll throw layers and layers of editors and reviewers at every stage of a book’s production. And when they’ve run out of editors, they’ll stage an editorial board review to make sure it wasn’t all a terrible mistake.

With some variation, that’s how the editors at Wiley/Sybex and Manning got their job done while working on my books. And it’s also quite similar to the process I go through producing my video courses with the Pluralsight team.

When it’s done properly, the system creates checkpoints at the theme, style, chapter, and even paragraph levels, asking whether this element is needed, is presented as well as it can be, and will fit properly into the greater vision. These checkpoints make for great books, but they tend to be very expensive.

Is it overdone? Sometimes. Is the full-blown multi-level editorial system going to be affordable for web-based documentation projects? Perhaps not always.

But creating high-quality, readable, and well-organized documentation is a significant business need for many companies, so it would probably be a really good idea for them to at least submit what they’ve already got to a thorough audit by someone with experience, technical knowledge, and — most important of all — objectivity. The odds are, that will lead to a far more useful documentation product. And yes: documentation is also a product.

David Clinton parks a lot of his goods at Bootstrap-IT.com. You might be surprised what you find there…

An introduction to Functional JavaScript

freeCodeCamp — Mon, 20 May 2019 17:31:24 +0000

By Cristian Salcescu

Hey everybody! I’ve written a book called Discover Functional JavaScript, and it’s now ready in both paperback and Kindle formats.

After publishing several articles on Functional Programming in JavaScript, at some point I realized I have enough material to think about a book. So, I started from my previous writings, filled in the missing parts and created a book on Functional Programming in JavaScript.

What I tried to do in this book was to give practical examples of the core functional concepts. I think that if we master the fundamentals then it will be easier to handle more complex situations. And this is what this book is for.

I looked into a deeper understanding of pure functions other than that they are great. If they are so good, why don’t we write the whole application using only pure functions?

The other reason behind the book is to emphasize the new way of building encapsulated objects without classes and prototypes in JavaScript. I even saw classes presented as a way to bring encapsulation to objects. Encapsulation means hiding information. Objects built with classes in JavaScript are built over the prototype system. All their properties are public, they are not encapsulated.

I tried and hope I have succeeded to present the fundamental functional programming concepts in an easy to learn and practical manner. After reading the book you will understand better concepts like first-class functions, closures, currying, and partial application. You will understand what pure functions are and how to create them. You will better understand immutability and how it can be achieved in JavaScript.

Another thing not taken so much into account is naming. With the rise of arrow functions, more and more anonymous functions are created. The pretext behind all this is the fact that arrow functions have no this and have a shorter syntax. I don’t challenge that, I just challenge the fact that meaningful names are what we understand best. Removing that will make code harder to understand.

The book is pretty condensed, so you can even read it a few times. In regard to the core JavaScript concepts, it aims to make an overview of them, not to enter into great detail. There are a lot of resources for that.

For me, it was a great experience trying to organize my thoughts to express these ideas in a simple, practical way. I tried to focus on the main practical concepts and just eliminate everything that ads no value to the reader.

A deeper understanding of the fundamental concepts in JavaScript makes us better at resolving complex problems. I hope you will like it.

Here is what you can find inside:

Chapter 1: A brief overview of JavaScript

JavaScript has primitives, objects and functions. All of them are values. All are treated as objects, even primitives.

Number, boolean, string, undefined and null are primitives.

Variables can be defined using var, let and const. The let declaration has a block scope.

Primitives, except null and undefined, are treated like objects, in the sense that they have methods but they are not objects.

Arrays are indexed collections of values. Each value is an element. Elements are ordered and accessed by their index number.

JavaScript has dynamic typing. Values have types, variables do not. Types can change at run time.

The main JavaScript runtime is single threaded. Two functions can’t run at the same time.

Chapter 2: New features in ES6+

ES6 brings more features to the JavaScript language. Some new syntax allows you to write code in a more expressive way, some features complete the functional programming toolbox, and some features are questionable.

let declaration has block scope.

function doTask(){   
  let x = 1;   
  {       
    let x = 2;   
  }

  console.log(x); 
}  
doTask(); //1

var declaration has function scope. It doesn't have block scope.

function doTask(){   
  var x = 1;   
  {       
    var x = 2;   
  }

  console.log(x); 
}  
doTask(); //2

Chapter 3: First-class functions

Functions are first-class objects. Functions can be stored in variables, objects or arrays, passed as arguments to other functions or returned from functions.

A higher-order function is a function that takes another function as an input, returns a function, or does both.

map() transforms a list of values to another list of values using a mapping function.

let numbers = [1,2,3,4,5];

function doubleNo(x){
  const result = x*2;
  console.log(`${x} -> ${result}`)
  return result;
}

const doubleNumbers = numbers.map(doubleNo);
//1 -> 2
//2 -> 4
//3 -> 6
//4 -> 8
//5 -> 10
//[2, 4, 6, 8, 10]

Chapter 4: Closures

A closure is an inner function that has access to the outer scope, even after the outer scope container has executed.

The count() function in the next example is a closure:

const count = (function(){
  let state = 0;
  return function(){
    state = state + 1;
    return state;
  }
})();

count(); //1
count(); //2
count(); //3

Chapter 5: Function decorators

A function decorator is a higher-order function that takes one function as an argument and returns another function, and the returned function is a variation of the argument function — Reginald Braithwaite, author of Javascript Allongé

The unary() decorator returns a new version of the function that accepts only one argument. It may be used to fix problems when the function is called with more arguments than we need.

function unary(fn){
 return function(first){
   return fn(first);
 }
}

const numbers = ['1','2','3','4','5','6'];
numbers.map(parseInt); 
//[1, NaN, NaN, NaN, NaN, NaN]

numbers.map(unary(parseInt)); 
//[1, 2, 3, 4, 5, 6]

Chapter 6: Pure functions

A pure function is a function that, given the same input, always returns the same output and has no side effects.

You may have seen examples of pure functions like the ones below and want to look at some practical examples of pure functions.

function double(x){
  return x * 2;
}

function add(a, b){
  return a + b;
}

function multiply(a, b) {
  return a * b;
}

Like other programming paradigms, Pure Functional Programming promises to make code easier to read, understand, test, debug, and compose. Can it deliver its promise? If it can, can we build an application using only pure functions? These are questions this chapter tries to answer.

Chapter 7: Immutability

An immutable value is a value that, once created, cannot be changed.

Does immutability have to do with variables that cannot change or values that cannot change? And how can we make that happen? Why do we even care about that? This chapter tries to answers these questions.

Chapter 8: Partial application and currying

Partial application refers to the process of fixing a number of parameters by creating a new function with fewer parameters than the original.

Currying is the process of transforming a function with many parameters into a series of functions that each takes a single parameter.

Usually we find examples using currying to add or multiply a few numbers, like in the code below:

function add(a) {
  return function(b){
    return function(c){
      return a + b + c;
    }
  }
}

add(1)(2)(3);
//6

Does currying have a practical application? This chapter shows some practical examples of using partial application and currying.

Chapter 9: Function composition

Function composition is applying one function to the result of another.

function compose(...functions){
  return function(x){
    return functions.reduceRight((value, f) => f(value), x);
  }
}

f(g(x)) === compose(f,g)(x);

Chapter 10: Intention revealing names

Functions can be created with or without a name. The arrow syntax usually creates anonymous functions.

(() => {
    /*code*/
    (() => {
        /*code*/
    })();
})();

Anonymous functions appear as “(anonymous)” in the CallStack.

Intention revealing names improve code readability.

Chapter 11: Making code easier to read

This chapter shows examples of refactoring imperative code with functional programming techniques and looks at the readability of the final code.

Chapter 12: Asynchronous programming

In an application, there are two kinds of functions: synchronous and asynchronous. We take a look at the asynchronous programming model in JavaScript.

Chapter 13: Objects with prototypes

Objects are dynamic collections of properties, with a “hidden” property to the object’s prototype.

Objects inherit from other objects.

class is a sugar syntax from creating objects with a custom prototype.

class Counter {
  constructor(){
    this.state = 0;
  }

  increment(){
    this.state = this.state + 1;
    return this.state;
  }

  decrement(){
    this.state = this.state - 1;
    return this.state;
  }
}

const counter = new Counter();
counter.increment(); //1
counter.increment(); //2
counter.increment(); //3
counter.decrement(); //2

Chapter 14: Objects with closures

With closures we can create encapsulated and flexible objects. Consider the same counter object created with closures:

function Counter() {
  let state = 0;

  function increment(){
    state = state + 1;
    return state;
  }

  function decrement(){
    state = state - 1;
    return state;
  }

  return Object.freeze({
    increment, 
    decrement
  })
}

const counter = Counter();
counter.increment(); //1
counter.increment(); //2
counter.increment(); //3
counter.decrement(); //2

This chapter presents more encapsulated objects and discusses the difference between objects built with closures and prototypes.

Chapter 15: Method decorators

Method decorators are a tool for reusing common logic.

Chapter 16: Waiting for the new programming paradigm

The last chapter contains thoughts on Functional and Object Oriented Programming in JavaScript.

Enjoy the book!

You can find me on Twitter.

Must-read books to learn Java programming

freeCodeCamp — Tue, 16 Apr 2019 17:14:52 +0000

By javinpaul

Hello everybody, today is the world of online courses. Everyone is talking about learning from online training, Youtube, free courses on Coursera and other websites, which is great as online courses to help you to learn faster, but, I believe books should still be an important part of your learning, as they provide the most in-depth knowledge and often written by authority on the subject matter.

If you are learning Java Programming, then be ready to be introduced to some of the most awesome books to learn and master Java Programming in this article.

Whenever a Programmer starts learning the Java programming language, the first question they ask is, “Which book should I refer to learn Java?” or “What is the best book to learn Java for beginners?” or “Can you tell me some good books to learn Java?” That, itself, says how important Java books are for programmers, especially beginners.

Despite having so many free resources available in Java, like tutorials, online courses, tips, blogs, and code examples, Java books have their own place because:

They are written by programmers who are an authority in the subject
They cover the subject with more details and explanation.

These Java books are my personal favorites, and whenever I get some time, I prefer to read them to refresh my knowledge. Though I have read many of them already (I have read Effective Java at least four times so far), I always want to learn something new and my quest for great books never ends.

These books are some of the best available today and are equally useful for beginners, intermediate, and advanced Java programmers.

It doesn’t matter whether you are completely new to Java or have been programming in Java for some time, you will learn a lot of new things through these books.

Having said that, not all books are equally suitable for all programmers. For beginners, Head First Java is still the best book to get started, and for the advanced Java developer, Effective Java is a nice book to start with.

10 Best Books to Learn Java Programming

Here is my collection of Java books that I suggest to every programmer who wants to learn Java. It contains books for both beginners and experienced programmers.

These books cover a variety of areas, including core Java fundamentals, the Java collection framework, multithreading and concurrency, JVM internals and performance tuning, design patterns, etc.

1. Head First Java

Many people will think that this is dated book, but to be honest Head First Java is the best book for any programmer who is new in both programming and Java. The head-first way of explanation is quite phenomenal and I really enjoyed their book.

Head First Java covers the essential Java programming knowledge about class, object, thread, collection, and language features, like Generics, Enums, variable arguments, or auto-boxing.

They also have some advanced section on Swing, networking, and Java IO, which makes them a complete package for Java beginners. This should be your first Java book you look at if you’re starting from scratch.

If you prefer online courses over books, then you can also check out Udemy’s Complete Java MasterClass course.

Disclaimer: this is not a free course, and I will receive compensation if you buy this course from Udemy or if you use any links to books listed here from Amazon.

2. Head First Design Patterns

The Head First Design Pattern is another top class Java book from the Head-First lab.

When I started reading this book back in 2006, I didn’t think much about design patterns, how they solve common problems, how to apply a design pattern, what benefits they provide, and all sort of basic things. But after reading this Java book, I have benefited immensely.

The first chapter on Inheritance and Composition, which is simply fantastic and promotes improved practices by introducing a problem and then the solution.

This book also contains helpful bullet points, exercises, and memory maps, which help you to understand design patterns quickly.

If you want to learn core Java design patterns and object-oriented design principles, this is the first Java book you should check out.

If you are looking for a course on GOF or object-oriented design patterns, I suggest you check out Design Pattern Library, one of the best courses I have attended on design patterns so far.

One point of good news about this book is that the new edition is updated for Java SE 8, which will teach you how to develop classic GOF design pattern using Java 8 features, like lambda expressions, and streams.

3. Effective Java

Effective Java is one of the top Java books in my record and one of the most enjoyable. I have high regard for Joshua Bloch, the author, for his contribution to the Java collection framework and Java Concurrency package.

Effective Java is best for a seasoned or experienced programmer who is well versed in Java programming. It’s great for programmers who want to share their skill by following programming best practices and who are eager to listen to someone who contributed to the Java development kit (JDK).

Effective Java consists of a collection of Java programming best practices, ranging from static factories, serialization, equals, and hashcode to generics, enums, varargs, and reflection.

This Java programming book covers almost every aspect of Java in a slightly different way than you are used to.

A new edition was released last year that introduced features in the JDK 7, 8, and 9, which was released last year in September. It also has a full chapter on lambdas.

4. Java Concurrency in Practice

Java Concurrency in Practice is another classic from Joshua Bloch, Doug Lea, and team. This is the best Java book on concurrency and multi-threading — one of the must-reads for core Java developers.

The strengths of Concurrency Practice in Java include:

1) This book is very detailed and captures minor details of multi-threading and concurrency

2) Instead of focusing on core Java classes, this book focuses on concurrency issues and problems, like deadlock, starvation, thread-safety, race conditions, and present ways to solve them using Java concurrency classes.

This book is an excellent resource to learn and master Java concurrency packages and classes, like CountDownLatch, CyclicBarrier, BlockingQueue, or Semaphore. This is the biggest reason I like to read this Java book and read it again and again.

3) One more strong point of concurrency practice in Java is the no-nonsense examples; the examples in this book are clear, concise, and intelligent.

4) This book is also good at explaining what is wrong and why it's wrong and how to make it right, which is essential for any Java book to succeed.

In short, this is one of the best books to learn concurrency and multi-threading in Java. The content is definitely advanced from a beginner’s perspective, but surely, this is a must-read book for experienced Java programmers.

5. Java Generics and Collections

The Java Generics and Collection by Naftalin and Philip Wadler from O’Reilly is another good book on Java, which I initially forgot to include in my list but am including it now as requested by many readers.

I like this book because of its content on generics and collections, which are core areas of the Java language.

Having a strong knowledge of Java collections and Generics is expected from an experienced programmer, and these books help in that area.

It explains each collection interface like Set, List, Map, Queue, and their implementation, comparing how well they perform in a different situation.

I really loved their comparison chart at the end of each chapter, which gives you a good idea about when to use a particular Java collection class, like ArrayList, HashMap, or LinkedHashMap.

6. Java Performance From Binu John

This is another good book that teaches about JVM internals, garbage collection, JVM tuning, profiling. etc, and I highly recommend every senior Java developer read this book. This is also one of my personal favorites.

As we are moving gradually, we started from a beginners level to intermediate and now the senior level.

The Java Performance is all about performance monitoring, profiling, and tools used for Java performance monitoring.

This is not a usual programming book. Instead, it provides details about JVM, Garbage Collection, Java heap monitoring, and profiling application.

I loved their chapter on the JVM overview, and it’s a must read to learn more about JVM in simple language.

Both beginners and an intermediate programmer can benefit from this book, but it’s good to have some Java experience under your belt before reading it. So far, this is the best Java book on performance monitoring.

This is another must-read Java book if you are serious about performance.

There are a couple of new books available in Java, which cover JDK 1.7. To find out latest book on Java performance like Java Performance, The Definitive Guide by Scott Oaks, which is certainly worth checking out before buying this book.

If you need some guidance on solving memory and CPU issues, I suggest you to also take a look at Understanding and Solving Java Memory Problems course by Richard Warburton.

7. Java Puzzlers

Java Puzzlers is another book worth reading from Joshua Bloch, this time with Neal Gafter. This book is about corner cases and pitfalls in the Java programming language.

Java is safer and more secure than C++, and the JVM does a good job to free the programmer from error-prone memory allocation and deallocation. But still, Java has corner-cases that can surprise even the experienced Java programmer.

This Java book presents such Java pitfalls and explains them in greater detail. This is a good Java book if you love puzzles — you can even include many of these in core Java interviews to check their Java knowledge.

I don’t rate it as high as Effective Java and Java Concurrency in Practice, but you can still give it a go, particularly to check your knowledge about Java and its corner cases, which will help you to answer some of the tricky Java questions from interviews.

In order to get most of this Java book, try to solve puzzles by yourself and then look into explanations to make your knowledge more concrete.

8. Head First Object-Oriented Analysis and Design

Another good book on Java programming and design principles from the Head-First series. Head First Object-Oriented Analysis and Design can be read in conjunction with Head First Design Patterns.

This book focuses on object-oriented design principles, like favor Composition over inheritance, programming for interface rather than implementation, DRY, etc.

One part of learning Java is writing good code and following the best practices, and this book is great in educating programmers about them.

Knowledge gained from this book is applicable to many object-oriented programming languages and will, overall, improve your understanding of code and OOP design principles.

9. Thinking in Java

Thinking in Java is written by Bruce Eckel, who is also the author of Thinking in C++ and uses his unique style to teach the Java concept.

Many would agree that this is one of the best Java books, with a strength being that is points to intelligent examples. This is one of the complete books in Java and can be used as a reference as well.

There is a chapter on Java memory mapped IO from Thinking in Java, which is my favorite.

If you don’t like the Head-First teaching style, but you need a beginners Java book with a plain example style, Thinking in Java is a good choice.

It is detailed, mature, and frequently updated, but, if you need more choices, you can check out these core Java books for beginners, as well.

10. Java SE 8 for the Really Impatient

This is one of the best books to learn Java 8. It is also my general purpose Java 8 books. If you have less time and you want to learn all important things about Java 8, this is the book to refer to.

I don’t have to remind you about Cay. S. Horstmann’s writing skill, one of the best authors in Java and right up there with Joshua Bloch. I have found both of them highly readable.

You won’t feel bored, which programmers often do when they read technical books. It explains about lambda expression, Streams, functional interface, method references, new Java Date Time API and several other small enhancement like joining Strings, repeatable annotations, etc. In short, one of the best book to learn Java hands down.

Wrapping up

This was my list of top Java programming books. I have read all the books, some of them I am still reading and a couple of them, like Effective Java and the Head-First series, I have read a couple of times. Many programmers ask me which books they should start with and which Java book they should read now. I hope you found some good books in this collection. Happy reading!

Other Useful Resources to Learn Java Programming
10 Things Java Programmer Should Learn in 2019
10 Tools Every Java Developer Should Know
10 Reasons to Learn Java Programming languages
10 Frameworks Java and Web Developer should learn in 2019
10 Tips to become a better Java Developer in 2019
Top 5 Java Frameworks to Learn in 2019
10 Testing Libraries Every Java Developer Should Know

Closing Notes

Thanks for reading this article so far. You might be thinking that there is so much stuff to learn, so many courses to join, but you don’t need to worry.

There is a good chance that you may already know most of the stuff, and there are also a lot of useful free resources which you can use — I have also linked to them here and there along with the other resources, which are certainly not free, but worth of money.

I am a particular fan of Udemy courses as they are very affordable and provide a lot of values in a very small amount, but you are free to choose the course you want.

At the end of the day, you should have enough knowledge and experience from using the resources mentioned here.

Good luck with your Java journey! It’s certainly not going to be easy, but by following this roadmap and guide, you are one step closer to becoming the Java Developer you always wanted to be

If you like this article then please consider following me on medium (javinpaul). If you’d like to be notified for every new post, don’t forget to follow javarevisited on Twitter!

Once again, all the best for your Java Development Journey and a Big thanks to all the authors for writing such awesome books. These top Java programming books are some of the best books to learn Java — I would even say that some of them are the best Java books ever published.

Books that Junior Developers should read

freeCodeCamp — Wed, 13 Mar 2019 13:23:21 +0000

By Khalil Stemmler

These books “are basically cheat codes” for leveling up your skills and knowledge as a developer.

Whether you’re a new developer or you’re fairly experienced as a programmer, you’ll come to realize that the amount of time you’ve worked at a job isn’t the best way to determine your skill and knowledge as a programmer (I know, tell that to the recruiters ?).

What you do in your spare time and how you choose to take learning into your own hands is what’s going to ultimately determine your success in this industry. That’s why it’s so important for us as developers to adopt a growth mindset.

There are some excellent ways to learn and improve as a developer. Some of those ways are pair-programming, online courses, meetups, work experience, building projects and finding a mentor.

One of my personal favorite ways to learn is to crack open a well-written book and try to absorb something from those who have distilled years of knowledge and insight into a permanent artifact.

Here are my personal recommendations that I think all developers (especially junior ones) should read at some point. These books are all highly regarded by professionals in our industry and have the potential to leave a profound impact on the quality of your work and your speed of development & learning.

Some of them stray from the technical details and focus more on giving you practical rules about what it means to be a good developer on the interpersonal and professional level.

Disclosure: Some of the links below are affiliate links. But, I’ve only added those books that I personally feel are useful for a junior dev.

1. Clean Code

by Robert C. Martin (Uncle Bob)

After you overcome the basic challenges of development and get comfortable figuring out how to write code to solve problems, it’d be a good idea to take a look at this book. It turns out that making the code work the first time is actually the easy part. The hard part is making your code read well so that others are able to understand it and change it in the future.

Remember the last time you had to read code like this?

function calculateIt (a, b) {
 if (a.delta < b.element.x) {
   var x = b.element.x;
   return x - b.delta.x
 } else {
   var y = b.next.y;
   var h = b.element.y * 2;
   return y - h
 }
}

Who knows what it really does. Code like this might work, but the moment we need to change it, we have to hope the author of the code is still in the company and pray that they are somehow able to decipher what they wrote potentially years ago.

When careful attention isn’t taken to write code that’s readable and maintainable, we end up with pockets of code like this that everyone is afraid to touch, and if it ever breaks, we’re in trouble.

Uncle Bob’s “Clean Code” teaches you how to identify what clean code looks like compared to bad code, and it teaches you how to transform it into good code. A task like this sounds trivial to most, but you’d be surprised at how turning a just a few clean software design principles into habits can help you write much more professional and scalable code.

We’re software craftspeople, you know. Building a house is not much different than building an application in principle. We need to pay attention to the details or else it can all become very expensive to fix in the future if not done right first time.

2. The Clean Coder

by Robert C. Martin (Uncle Bob)

This book is not necessarily a technical book as it is a book for teaching you how to be a professional in this industry. Professionals are those who, when faced with challenges, uncertainty and pressure, will continue to treat creating software as a craft and will be determined to adhere to their professional values.

The Clean Coder is full of practical advice on estimation, refactoring, testing, dealing with conflict, schedules, avoiding burnout, and much more. Trusted advice from someone who has spent decades doing this stuff.

One of the best things it teaches, is how to have integrity as a developer, when to say “No” and how to say it.

A book about professionalism.

3. Refactoring

by Martin Fowler

Martin Fowler is one of my favorite authors. The first reason is that he’s hilarious. His approach to writing software books is unmistakably “Fowler”. The other reason is that he’s incredibly good at explaining complex topics, and doing so very simply, in a way that doesn’t fatigue you as a reader.

Refactoring is a book that the creator of Ruby on Rails once said that you should “read before you write another line of code”. Fowler guides you through refactoring a simple application, introducing you to a number of techniques that he’s accumulated and cataloged over his years of consulting.

Fowler shows you how to flip between coding and refactoring, how often you should be committing your code and when you should be writing your tests. Highly recommended. The latest version of this book was updated to present the examples in JavaScript, which was an added plus for me since it’s my favorite language.

4. Design Patterns: Elements of Reusable Object-Oriented Software

by Erich Gamma, Richard Helm, Ralph Johnson, & John Vlissides

This is the seminal book on Design Patterns. What are design patterns, you ask? Design Patterns are well-known solutions to commonly occurring problems in software development. If you’re familiar with the patterns, you’ll find that you’ll be able to greatly reduce the amount of time it takes you to put forth the solutions to those problems.

Having a good awareness of design patterns also allows you to communicate your solutions effectively with other developers.

“Yeah, I just used a Facade overtop of whichever database Adapter gets loaded from the Strategy.”

“Ahh! Gotcha.”

Yeah, it’s an older book. But it’s still one of the best for reference. If you’d like something on this topic that’s a bit more recent and friendly, I’d also recommend the good “Head First Design Patterns: A Brain-Friendly Guide” by Eric Freeman.

5. Domain-Driven Design: Tackling Complexity in the Heart of Software

by Eric Evans

In order for large code bases to continue to scale, we need to logically split up code into different parts. The idea is to partition your code in a way such that it would be possible for separate teams to work on those parts of your system without affecting anyone else.

The underlying concept that enables moving your code base in this direction is Domain-Driven Design (DDD). It’s an approach to software development where we model the problems that exist in the “problem domain” (the real world) to a number of solution domains.

DDD is incredibly important when a code base gets sufficiently large. Large enterprise companies employ DDD in order to assign teams to parts of the company’s code base.

Eric Evan’s coined the term “Ubiquitous Language”, which is the term for building a common, all-encompassing language between the developers, the domain experts and any other users or actors in the domain. By using this Ubiquitous Language, it ensures that the most important domain concepts are well understood and get modeled in the software.

The book is a little more technical and challenging than the others, but if you get familiar with these concepts, you’ll be very well off in understanding how today’s largest companies keep their code bases manageable and scalable.

Update: April 17th, 2019

I’ve thought about this recommendation a little bit. Introduction to the DDD world is, in my opinion, extremely beneficial for Junior Developers. I believe this to be true because DDD places importance on familiarity with software architecture, design principles and design patterns. It’s a great way to practically introduce yourself to a higher level of programming.

That said, DDD is a large and challenging topic. For some readers, this book (the seminal “blue book”) by Eric Evans might be better treated as a reference. It was Eric Evans who wrote the first book on DDD.

However, I just recently finished reading DDD Distilled by Vaughn Vernon. It’s a really short and sweet intro to DDD, written in order to address the fact that most books on DDD are huge in size.

Definitely try DDD Distilled instead. I think this book would be a lot better for most developers in order to get ramped up on the DDD essentials first. For more practical details on how to implement the concepts, refer back to “the blue book” and “the red book”.

6. Soft Skills: The Software Developer’s Life Manual

by John Sonmez

We should strive to stay well-balanced as a software developer. Unfortunately, being well-balanced is not a trait that most people affiliate with software developers. The truth is, it’s incredibly important to invest in your learning, health and overall well-being as a developer.

“Soft skills” is about the important stuff that matters outside of actually coding, like productivity, career goals and personal finance. Sonmez also goes into investing, how he retired at 33, fitness hacking tips and maintaining relationships - things rarely addressed in the programming community.

It’s written in such a way that you can jump into the book at whichever chapter you think is most relevant to you today.

7. Clean Architecture

by Robert C. Martin (Uncle Bob)

What? Uncle Bob writes good books, ok?

In school, there’s a lot of focus on algorithms and less focus on software design principles. I think it’s kind of unfortunate because in reality, you don’t encounter that many algorithm challenges too often. Instead, it’s more common that you’ll be faced with the challenge of structuring your code in a way that’s modular, flexible, readable and will allow you to add new features quickly when requirements change.

Clean Architecture is about the essential software design principles and patterns that you’ll be able to use in order to face these challenges.

Some of the best takeaways from this book are the cost of dependencies, stable vs. non-stable code and the SOLID principles: a way to write code so that it’s more understandable, flexible and maintainable.

Other aspects of this book that were incredibly useful were concepts of “screaming architecture” and “packaging by component” which are opinions on how to organize your modules so that it practically screams to the reader exactly what the project is all about.

This book goes well hand-in-hand with Domain-Driven Design, which is enabled through the use of a “Layered Architecture” or as Uncle Bob calls it, “The Clean Architecture” (also known as Ports and Adapters). A great book for anyone who wants to up their architecture chops and learn how to effectively design a system at a high level, and do the dance of dependencies at the detail level.

8. The Effective Engineer

by Edmond Lau

Time is our single most valuable asset in life, and we should aim to be more efficient with it. It’s easy to get bogged down and spend a lot of time fixing bugs and wasting effort. Doing repeated work. Bleh. The Effective Engineer is all about getting more done in less time and removing repeated work.

We can mitigate wasted time and effort on repetitive tasks through a framework called “leverage”.

Leverage helps you identify the activities that you can do that produce the most disproportionate results- per unit of time invested. It’s a framework that can apply to anything, whether that be how you learn, how you code, how you debug… anything!

9. The Pragmatic Programmer

by Andrew Hunt & David Thomas

Praised for being easy to follow and understand, The Pragmatic Programmer is a book that should be on the desktop of developers of all levels. Andrew and David are programmers that not only spent many years doing what they do, but paying attention to what they were doing as they were doing it, and then trying to determine if they could do that better.

What came out of their years of introspection was this book, which introduces a number of essential programmer philosophies to follow throughout your career, like “programmers should have a “do it once, or automate” philosophy”.

It includes simple yet detailed advice that you should carry with you in the back of your mind before you write another line of code or start a new project.

Final Words

Books really are some of the best tools to improve your knowledge and skills as a new programmer or Junior Developer. Books tend to have a really high return on investment; did you know you can make a lot of money programming? ?

These are just a few of the best books out there right now in 2019! None of them are really new, but that’s because programming has maintained the same general philosophies and best practices for years. As a professor I once had to say, “you can make a lot of money in this industry, you just have to read the damn manual”.

Have you read any of these books? What did you think? Any books not on this list that you think newer developers would really benefit from reading? Let us know in the comments!

Additional Resources

Here’s a list of some really excellent articles that cover some of the topics from these books. If you don’t quite have the time to invest in fully blown books right now, familiarizing yourself with these concepts might assist you in your journey to become a better developer!

Surviving Your First Junior Developer Job [Guide] ??
https://univjobs.ca/blog/developer-guides/ultimate-guide-for-first-junior-developer-job-success/

Refactoring.guru
https://refactoring.guru/

SOLID Design Principles
https://stackify.com/solid-design-principles/

DRY (Don’t Repeat Yourself)
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

NodeJS and Good Practices
https://blog.codeminer42.com/nodejs-and-good-practices-354e7d76362

Implementing the SOLID and the onion architecture in Node.js
https://dev.to/remojansen/implementing-the-onion-architecture-in-nodejs-with-typescript-and-inversifyjs-10ad

Better Software Design with Clean Architecture
https://fullstackmark.com/post/11/better-software-design-with-clean-architecture

The Clean Architecture
http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

My upcoming free resource, an introduction to software architecture and design principles with Node.js and TypeScript

https://khalilstemmler.com/resources/solid-nodejs-architecture

Keep growing, and have fun while you’re at it!

If you’re a Canadian student or recent-grad looking for entry-level developer opportunities or co-ops/internships, you should check out our platform, Univjobs. We only post jobs specifically for students and recent-grads.

How to launch your own open source book that’s popular and profitable

freeCodeCamp — Tue, 03 Oct 2017 20:29:18 +0000

By Baptiste Pesquet

I am the author of The JavaScript Way, a self-published open source book for learning to code. Despite the lack of any initial audience, it topped GitHub trending charts worldwide during its launch.

This is the story of this unexpected success.

Project inception

At the beginning of this project, I explained why I started it and went over some of my initial choices. In short:

There was a need for a book teaching modern JavaScript to beginners.
I decided to self-publish this book and write it in the open on GitHub. Doing so, I was hoping to reach as many people as possible. Also, to leverage the great collaborative model that is at the heart of open source.
The book would have a Creative Commons BY-NC-SA license. It allows anyone to share or build upon my work as long as some rules are observed. In particular, no commercial purposes outside of mine are allowed.

Also, some key factors in the decision were:

Text is still a great medium to convey knowledge. So, the choice of a book instead of some video-based material.
I already authored two online courses on the same topic (here and there). The feedback for them has been very positive, so I knew that I had some pretty solid content at hand.
I wanted to hone my JavaScript skills, and knew firsthand that teaching something is a great way to master it.

What I lacked was an initial audience, something often seen as a critical asset for this kind of project. Since someone has to start somewhere, I went on anyway.

Choosing a business model

Every creator faces the same dilemma. How to share your work with the world that would make an impact and also be profitable? There is no definitive answer to this age-old question.

The digital revolution has turned things upside down for authors. It has lowered the distribution and sharing costs to zero. In our “reputation economy”, content creators must battle to gain consumer attention. As a new player in this field, meeting success will be very difficult if all your content sits behind a paywall. Some of it has to be available for free.

For authors, the most common marketing tactic is now to split your work into several parts. The first one free, gives potential customers a glimpse of your content and style. In the hope that hooked up customers will buy the other parts.

Kyle Simpson’s alternative choice for its quite successful You Don’t Know JS book series appealed to me. Like him, I decided to give away the entire book content for free, but let users pay for a better reading experience through the ebook version.

Taking example from another self-published bestseller, I chose to include coding exercises and projects right into the book, but sell their solutions as an extra.

This “hybrid” business model seemed a reasonable balance between openness and potential profit.

Building an audience (or not)

Another common marketing advice is building some audience through a mailing list, using some existing content (for example, your own blog) as a magnet.

I don’t like this approach very much and didn’t want to bother my readers with any subscription.

I also considered launching a crowdfunding campaign. Without any initial audience, this seemed to me as a lot of work for a very uncertain outcome, so I shied away from it. Maybe next time!

Tools and process

The very best file format for authoring any book (not only technical ones) is plain text. No need for a dedicated editor. No interoperability issue. The ability to use a version control system like Git to keep track of changes.

Among the various text-based markup languages available. I chose Markdown because I already knew and liked its syntax. Markdown is also a first-class citizen on GitHub, which was essential for this project.

A self-published author needs a toolchain to transform the raw manuscript files into various ebook formats (PDF, EPUB, MOBI). For me, the Leanpub platform ticked all the boxes: Markdown support, integration with GitHub and a fair royalty structure (90% minus 50 cents per sale).

I used the free text editor Visual Studio Code for authoring the book files on my computer. It has great Markdown support out of the box and a very convenient side-by-side file preview (see image below). Extensions like Markdown Shortcuts and markdownlint can be installed to become even more productive.

After all tools were chosen, I drafted the book outline (a very important first step) using my previous courses as a basis. Then I dived into the writing process.

Early publishing

Leanpub’s motto is “Publish early, publish often”. The platform empowers you to publish early drafts of your work. Receive feedback and create traction, enabling an MVP-like approach to book authoring.

It’s a great idea on paper… Which unfortunately didn’t work at all for me. One month after the writing process started, I made the book public on Leanpub. By that time, the ebook price was $0, so anyone could get it for free.

I told my personal network about it, twitted about it, submitted it to Reddit and Hacker News. I also reached out to other book authors or prominent individuals. I also reached out to Kyle Simpson, Robin Wieruch and freeCodeCamp’s Quincy Larson, looking for advice and support.

The outcome was a mixed bag. A few GitHub stars, a handful of messages on Twitter and Reddit. An HN thread that went out-of-topic and got buried. Execution was poor, the lack of any initial audience was too much of a disadvantage there.

A majority of comments were like “Ping me back when it’s finished”. People may not want to invest time to read in-progress books, which is understandable after all.

But, individual responses from Kyle, Robin and Quincy were hearthwarming. They played a big role in keeping me motivated. I’m very thankful to them.

The writing phase

Even after this underwhelming early launch, I was still convinced that my book was worth something. I didn’t want to give up after having already spent dozens of hours on it. Using an unchanged book outline, I went for a no-feedback route and kept on writing all by myself until the book got finished.

That was the hardest part. Spending countless hours, day after day, only to see things take shape very slow. Inevitably, doubts surface: how could it ever succeed? Is this all a giant waste of time? Why am I inflicting this to myself?

The key to overcome these obstacles is putting the right amount of pressure on yourself. If your time commitment is too scarce, you will lose motivation and give up. But, trying to move forward too fast, neglecting other important aspects of your life along the way, is risky on many levels.

After all, this was only a side project. Low risk, low pressure! Self-publishing means I had no deadlines to meet, which can be both a blessing and a curse. I tried to use this to my advantage: I was free to invest time in something I believed into, but at my own pace.

I found a reasonable balance (about 10–15 hours a week) between work, personal life and the writing process. Limited long and hazardous breaks. This article on side projects gives useful advice to keep things going during this phase.

My commit statistics on GitHub during the writing phase

Luckily, I had some existing material to build upon. Some experience writing content on my own… And also a very understanding spouse ;)

Launch day

After eight months of steady work and a few last hours feverishly spent fixing things here and there, my book was ready at last!

The upside of writing in a vacuum like I did is that your book launch becomes a pretty big event. After such a huge time investment, it’s a great feeling (and also a huge relief) to show your finished creation to the world.

For lack of anything better, I reused my previous launch strategy. Twitter, Reddit and Hacker News (timing submissions for most visibility). Also, the same nice people that kept me motivated after the early launch.

To my astonishment, the result was this time overwhelmingly positive. Kyle Simpson and Quincy Larson kindly tweeted about the book to their dozens of thousands of followers.

Hour after hour, I watched in awe of disbelief as rave comments and retweets piled into my inbox. I finally knew that my book would have an impact.

Launch is also the blissful moment where the magic of open source happens. People can read and share your book for free. Creating traction without any marketing effort. But they can also improve its quality through contributions using GitHub issues and pull requests.

Since I’m not an English native and didn’t have an editor by my side to proof check the content. I knew that my book contained many typos and errors at launch. I hoped people would help to spot and correct them, and wasn’t disappointed.

Here are a few figures gathered two days after launch:

The book repository on GitHub had more than 51k views from 17k unique visitors. The bulk of this traffic came from Hacker News, followed by Reddit.
It gained more than 2,400 stars, and becoming the #1 trending repoworldwide for a day.
The Hacker News story climbed to #5 rank on the front page, generating more than a hundred comments.
Readers submitted 30 pull requests, correcting many of the book’s initial mistakes. Small typos for the most part, but also grammatical improvements and even a few coding errors.
I already received two translation requests, to Spanish and Chinese.

All in all, far more than what I could dream of.

Financial outcome

Can an open source book be profitable after all? Of course, it’s too soon to tell. Two days after launch, it became Leanpub’s bestselling book of the week, with more than $1,000 in royalties.

Leanpub royalties dashboard two days after launch

Profitability was not the reason this project was started in the first place. Yet the hybrid pricing model, with free sources and paid ebook/corrections, will ultimately contribute to the book’s reputation while making for some welcome passive income.

Later on, I may create a paperback version of the book (Maybe Amazon CreateSpace) if there is any demand for it. An interactive online course offering a richer user experience is already under way.

Most importantly, I have the deep satisfaction of having contributed something meaningful to the community. Thousands of people around the world will use my book to learn to code, improve at JavaScript and it may change their lives for the better.

And that is priceless.

Conclusion

It wasn’t all roses, but self-publishing a successful open source book without any prior audience is definitely possible.

I hope this little story has entertained you. I also hope it might inspire you to start a creative project on your own, be it a book or something completely different.

I look forward to see what you will achieve!

How I used machine learning to explore the differences between British and American literature

freeCodeCamp — Fri, 13 Jan 2017 13:58:43 +0000

By Sofia Godovykh

As I delved further into English literature to further my own language gains, my interest was piqued: how do American and British English differ?

With this question framed in my mind, the next steps were to apply natural language processing and machine learning techniques to find concrete examples. I was curious to know whether it would be possible to train a classifier, which would distinguish literary texts.

It is quite easy to distinguish texts written in different languages since the cardinality of the intersection of words (features, in terms of machine learning) was relatively small. Text classification by category (such as science, atheism, computer graphics, etc.) is a well-known “hello world” when it comes to tasks related with working with text classification. I faced a more difficult task when I tried to compare two dialects of the same language, as texts have no common theme.

The most time consuming stage of machine learning deals with the retrieval of data. For the training sample, I used texts from Project Gutenberg, which can be freely downloaded. As for the list of American and British authors, I used names of authors I found in the Wikipedia.

One of the challenges I encountered was finding the name of the author of a text that matched the Wikipedia page. A good search by name was implemented on the site, but since the site doesn’t allow the parsing of data, I instead proposed to use files that contained metadata. This meant that I needed to solve a non-trivial task of matching names (Sir Arthur Ignatius Conan Doyle and Doyle, C. is the same person, but Doyle, M.E. is a different person) — and I had to do so with a very high level of accuracy.

Instead, I chose to sacrifice the sample size for the sake of attaining high accuracy, as well as saving some time. I chose, as a unique identifier, an author’s Wikipedia link, which was included in some of the metadata files. With these files, I was able to acquire about 1,600 British and 2,500 American texts and use them to begin training my classifier.

For this project I used sklearn package. The first step after the data collection and analysis stage is pre-processing, in which I utilized a CountVectorizer. A CountVecrorizer takes a text data as input and returns a vector of features as output. Next, I needed to calculate the tf-idf (term frequency — inverted document frequency). A brief explanation why I needed to use it and how:

For example, take the word “the” and count the number of occurrences of the word in a given text, A. Let’s suppose that we have 100 occurrences, and the total number of words in a document is 1000.

Thus,

tf(“the”) = 100/1000 = 0.1

Next, take the word “sepal”, which has occurred 50 times:

tf(“sepal”) = 50/1000 = 0.05

To calculate the inverted document frequency for these words, we need to take the logarithm of the ratio of the number of texts from which there is at least one occurrence of the word, to the total number of texts. If there are all 10,000 texts, and in each, there is the word “the”:

idf(“the”) = log(10000/10000) = 0 and

tf-idf(“the”) = idf(“the”) * tf(“the”) = 0 * 0.1 = 0

The word “sepal” is way more rare, and was found only in the 5 texts. Therefore:

idf(“sepal”) = log(10000/5) and tf-idf(“sepal”) = 7.6 * 0.05 = 0.38

Thus, the most frequently occurring words carry less weight, and specific rarer ones carry more weight. If there are many occurrences of the word “sepal”, we can assume that this is a botanical text. We can not feed a classifier with words, we will use tf-idf measure instead.

After I had presented the data as a set of features, I needed to train the classifier. I was working with text data, which is presented as sparse data, so the best option is to use a linear classifier, which works well with large amounts of features.

First, I ran the CountVectorizer, TF-IDFTransformer and SGDClassifier using the default parameters. By analyzing the plot of the accuracy of the sample size — where accuracy fluctuated from 0.6 to 0.85 — I discovered that the classifier was very much dependent on the particular sample used, and therefore not very effective.

After receiving a list of the classifier weights, I noticed a part of the problem: the classifier had been fed with words like “of” and “he”, which we should have treated as a noise. I could easily solve this problem by removing these words from the features by setting the stop_words parameter to the CountVectorizer: stop_words = ‘english’ (or your own custom list of stop words).

With the default stop words removed, I got an accuracy of 0.85. After that, I launched the automatic selection of parameters using GridSearchCV and achieved a final accuracy of 0.89. I may be able to improve this result with a larger training sample, but for now I stuck with this classifier.

Now on to what interests me most: which words point to the origin of the text? Here’s a list of words, sorted in descending order of weight in the classifier:

American: dollars, new, york, girl, gray, american, carvel, color, city, ain, long, just, parlor, boston, honor, washington, home, labor, got, finally, maybe, hodder, forever, dorothy, dr

British: round, sir, lady, london, quite, mr, shall, lord, grey, dear, honour, having, philip, poor, pounds, scrooge, soames, things, sea, man, end, come, colour, illustration, english, learnt

While having fun with the classifier, I was able to single-out the most “American” British authors and the most “British” American authors (a tricky way to see how bad my classifier could work).

The most “British” Americans:

Frances Hodgson Burnett (born in England, moved to the USA at age of 17, so I treat her as an American writer)
Henry James (born in the USA, moved to England at age of 33)
Owen Wister (yes, the father of Western fiction)
Mary Roberts Rinehart (was called the American Agatha Christie for a reason)
William McFee (another writer moved to America at a young age)

The most “American” British:

Rudyard Kipling (he lived in America several years, also, he wrote “American Notes”)
Anthony Trollope (the author of “North America”)
Frederick Marryat (A veteran of Anglo-American War of 1812, thanks to his “Narrative of the Travels and Adventures of Monsieur Violet in California, Sonara, and Western Texas” which made him fall into the american category)
Arnold Bennett (the author of “Your United States: Impressions of a first visit”) one more gentleman wrote travel notes
E. Phillips Oppenheim

And also the most “British” British and “American” American authors (because the classifier still works well):

Americans:

Francis Hopkinson Smith
Hamlin Garland
George Ade
Charles Dudley Warner
Mark Twain

British:

George Meredith
Samuel Richardson
John Galsworthy
Gilbert Keith Chesterton
Anthony Trollope (oh, hi)

I was inspired to do this work by @TragicAllyHere tweet:

Well, wourds really matter, as I realised.

A Cognitive Sciences Reading List for Designers

freeCodeCamp — Fri, 29 Jul 2016 01:11:56 +0000

By Andy Fitzgerald

If you’ve ever done any contextual inquiry or usability testing, you’ve probably observed first hand the difference between what people say they will do and what they actually end up doing. Overlooked calls to action, bizarre navigation paths, mind-bogglingly irrational decisions — even the most sensible seeming users occasionally (or often) do things that “rationally” make little sense.

Which is to say that we all, on occasion (or often) do things that seem to make little rational sense.

And yet, on a day-to-day basis, this is how we successfully negotiate the complexities of our world. We use heuristics (aka rules-of-thumb) and limited information to make decisions about how we live our lives, and we do it continuously throughout the day — often without stopping to consider why we choose one thing over another.

In order to get a better sense of how our often erratic decision making processes work behind the scenes — and better understand why they sometimes don’t — I’ve been doing more reading lately into cognitive science and decision making. This post is a quick roundup of the books I’ve found most enlightening to the task of designing information systems for messy, irrational humans.

Embodied & Distributed Cognition

There’s been a lot of attention given lately to the idea that “thinking” doesn’t take place solely in the space between our ears. Modern notions of cognition understand thinking as a process that crosses into the body and spills out into the world. For a deeper understanding of how thinking is embodied and distributed, these texts are a good place to start:

Beyond the Brain

Louise Barrett, 2011

Theme

It is an error to assume that complex behavior and complex cognition are necessarily linked and that the one can only arise from the other. By understanding how brains, bodies, and environment are connected, we can better understand how intelligent, adaptive behavior is produced.

Key Concepts

“To make a distinction between perception and cognition as separate psychological processes is both arbitrary and false” (22).
“Language is not purely for communicating, but is also a way of effecting changes in our environment that enable us to achieve more than we could otherwise” (194).
“The real ‘problem solving machine’ is not the brain alone, but the brain, the body, and the environmental structures that we use to augment, enhance, and support internal cognitive processes” (219).

Impressions

Very readable with lots of relatable examples and relevant context. This book draws on and furthers a wide body of foundational work (Andy Clark figures in here a lot — we’ll get to him in a minute), but remains accessible to a general audience.

Proust and the Squid

Maryanne Wolf, 2007

Theme

The process of learning to read creates physical changes in the brain that directly affect how that brain works and how we think. Understanding this process (neuroplasticity) in the reading brain prepares us to better understand the changes we’re currently undergoing as we “make the transition from a reading brain to an increasingly digital one.”

Key Concepts

The efficient reading brain — which takes years to develop — literally has “more time to think” (54).
Contrary to spoken language, “there are neither genes nor biological structures specific only to reading. Instead, in order to read, each brain must learn to make new circuits by connecting older regions originally designed and genetically programmed for other things” (168).
“The new circuits and pathways that the brain fashions in order to read become the foundations for being able to think in different, innovative ways” (271).

Impressions

The first part of this book focuses on the plasticity of the brain and the ways that learning to read changes it. Wolf illustrates this story with historical accounts of writing in early societies and plenty of good ol’ neuroscience. Later chapters focus more closely on reading development in children and dyslexia before returning in a brief final chapter to the effects of digital technology on how our brains work.

Supersizing the Mind

Andy Clark, 2008

Theme

What we call “thinking” often occurs only partially in the brain: much of the human cognitive process regularly criss-crosses the boundaries of brain, body, and environment. “In building our physical and social worlds, we build (or rather, we massively reconfigure) our minds and our capacities of thought and reason” (xxviii).

Key Concepts

“Words and linguistic strings are among the most powerful and basic tools we use to discipline and stabilize dynamic processes of reason and recall” (53).
“Gesture and speech are interacting parts of a distributed, semianarchic cognitive engine, participating in cognitively potent self-stimulating loops whose activity is as much an aspect of our thinking as its result” (133).
“The presence of humanlike minds depends quite directly on the possession of a humanlike body” (200).

Impressions

Clark makes a compelling and provocative case for radically rethinking the way human beings perceive, think, and act in the world; for him, all of these actions are part of a single, continuous process. Clark supports his claim by drawing on a wide range of sources in linguistics, robotics, biology, and neuroscience — from which he pulls a variety anecdotes and examples that keep the text humming along. Big ideas here and intense reading; well worth the effort.

Meaning Making

Ferdinand de Saussure, the founder of linguistics, argued that without language, we wouldn’t have thought. Figuring out how we make meaning has lot to do with how we use and manipulate symbols. This field is plenty deep, but these titles will give you some practical ways to think about how “saying” and “meaning” relate:

Metaphors We Live By

George Lakoff and Mark Johnson, 1980

Theme

We have all at one time been taught to recognize a “metaphor” as a figure of speech, a particular use of language. Lakoff and Johnson argue that, to the contrary, metaphor as a linguistic expression is possible only because the human conceptual system and thought process is, at its core, metaphorically defined.

Key Concepts

“Our values are not independent but must form a coherent system with the metaphorical concepts we live by” (22).
Even seemingly literal expressions are often structured by metaphorical concepts which highlight some aspects of experience while hiding others (51, 149).
Since truth is always relative to a conceptual system, and since any human conceptual system is mostly metaphorical in nature, there can be no fully objective, unconditional, or absolute truth (185).

Impressions

This book is a great first foray into the subtleties of how we use language and metaphor to construct meaning and make sense of the world. Lakoff and Johnson drive the narrative with examples out of everyday language and take the time to thoroughly explain their conclusions. This book is definitely one of my favs.

Seeing What Others Don’t

Gary Klein, 2013

Theme

Insight is not the result of concentration or a proven process, but rather of learning to “restructure beliefs.” To nurture the power of insight, we must change the story we use to understand events.

Key Concepts

“Intuition is the use of patterns we’ve already learned, whereas insight is the discovery of new patterns” (27).
“Insights change our understanding by shifting the central beliefs — the anchors — in the story we use to make sense of events” (148).
“Confusions, contradictions, and conflicts can work as springboards to insight. We just have to replace our feelings of consternation with curiosity” (182).

Impressions

Klein’s book is the record of his own quest to figure out what sparks insight — and to figure out what keeps us from grasping insight that is right in front of us. He explores these questions, as well as the question of how to increase the flow of insight, across scores of stories of insight achieved (and missed). Very readable, very engaging.

The Way We Think

Gilles Fauconnier with Mark Turner, 2003

Theme

Identity, integration, and imagination are the result of the uniquely human ability to “blend” mental spaces by projecting elements from one frame of reference to another. This “cognitive blending” is the core process behind the human power to construct meaning.

Key Concepts

“Meaning systems and formal systems are inseparable. They co-evolve in the species, the culture, and the individual” (11).
“The meanings we take most for granted are those where the complexity is best hidden” (24).
“Language does not represent meaning directly; instead, it systematically prompts the construction of meaning” (142).

Impressions

The Way We Think provides one of the most meticulous, in depth readings of how humans construct meaning I have ever read. The examples given range from “Eureka!” moments, where we are shown the core inner workings of sudden realization and certainty, to constructions of the most banal everyday speech, revealed to contain complex operations of imaginative blending and synthesis. A less patient reader may find some of the case studies tedious, but the core framework and analytical approach offered here provides a powerful set of tools for digging deep into how we construct and communicate meaning.

Women, Fire, and Dangerous Things

George Lakoff, 1990

Theme

We organize knowledge by means of structures called “idealized cognitive models,” which account for our ability to categorize and conceptualize. These models emerge from the basic, experiential aspects of human psychology: “gestalt perception, mental imagery, motor activities, social function, and memory” (37).

Key Concepts

“Motivation depends on overall characteristics of the conceptual system, not just local characteristics of the category at hand” (113).
“Since we act in accord with our conceptual systems and since our actions are real, our conceptual systems have a major role in creating reality” (296).
“Reason is embodied in the sense that the very structures on which reason is based emerge from our bodily experience. Reason is imaginative in the sense that it makes use of metonymies, metaphors, and a wide variety of image schemas” (368).

Impressions

“Women, Fire, and Dangerous Things” is the 500 ton locomotive of this list — and it doesn’t come with brakes. This is a big book full of big ideas, some of which you’ll follow, some of which you likely won’t. Don’t worry about it. Success means grappling with it, not defeating it. That said, there is a lot in here for the diligent reader. I’m particularly fond of chapter 17, “Cognitive Semantics.”

Decision Making

You’re a rational person, right? You make rational decisions, right? Alas, this is what everyone thinks — and we collectively have pretty varied opinions (to say the least) about what counts as “rational.” Dig these books to get some insight into why:

Predictably Irrational

Dan Ariely, 2008

Theme

Standard economic theory suggests that individuals make decisions based on carefully weighed consideration of their options. In practice, however, “rationality” is regularly eclipsed by our irrational feelings about initial states (anchors), the temptation of getting anything for free, social norms, and the outsized value we place on what we already possess (loss aversion).

Key Concepts

“Once prices are established in our minds — even if they’re arbitrary — they shape not only what we are willing to pay for an item, but also how much we are willing to pay for related products” (32).
“The difference between two cents and one cent is small; the difference between once cent and zero is huge” (68).
“Our propensity to overvalue what we own is a basic human bias, and it reflects a more general tendency to fall in love with, and be overly optimistic about, anything that has to do with ourselves” (182).

Impressions

This is one of the most accessible texts on this list: Ariely writes in an easy-going, conversational style and structures all of his arguments around closely focused, often funny studies and experiments he has himself conducted with students and colleagues. His examples are great both at illustrating his points and keeping his reader engaged.

Thinking, Fast and Slow

Daniel Kahneman, 2011

Theme

We use two cognitive processes to evaluate information: a fast, always-on, but error-prone automatic system, and a more effective, analytical but effortful deliberate system. The trouble we get into is that we sometimes mistake automatic and error-prone decisions for well-considered, analytical ones — sometimes to the point of consciously making decisions that are opposed to our best interests.

Key Concepts

Why we fail at statistics: “our mind is strongly biased toward causal explanations and does not deal well with ‘mere statistics.’ When our attention is called to an event, associative memory will look for its cause — more precisely, activation will automatically spread to any cause that is already stored in memory” (182).
What You See is All There Is (WYSIATI): “You cannot help dealing with the limited information you have as if it were all there is to know. You build the best possible story from the information available to you, and if it is a good story, you believe it. Paradoxically, it is easier to construct a coherent story when you know little, when there are fewer pieces to fit into the puzzle. Our comforting conviction that the world makes sense rests on a secure foundation: our almost unlimited ability to ignore our ignorance” (201).
In misunderstanding statistical possibility, we end up paying a premium (sometimes an exorbitant one) for security from unlikely events, while at the same time gambling resources regularly on equally unlikely events. Chapter 29 (and much of the book, really).

Impressions

This book is a fascinating and compelling read. Kahneman’s examples are clear and easy to follow — and their implications are sobering (if not terrifying). I’ve talked to a lot of folks who have started this book, but never quite finished it. At 400 + pages, it’s a bit longer than some other texts on this list, but I definitely recommend reading it all the way to the end — it’s all good stuff, especially if you’re trying to understand why people (perhaps including yourself) make the decisions they do in the face of uncertain outcomes.

And There You Have It

Now: I’m not going to claim that this list isn’t challenging, or that you should be able to knock these out in a couple weekends. If you’re interested in digging into the prickly problems of designing for the complex systems that crop up when we mix data, choice, and the human decision-making process, though, these books will give you plenty to think about.

Even more than that, all of them should give you additional frames of reference from which to consider the messy, human challenges we face as designers every day. Principles like Daniel Kahnemman’s “What You See Is All There Is” or Fauconnier & Turner’s “cognitive blending” will give you new ways to pop your thinking out of the “best practices” ruts you might have fallen into and look for solutions to messy human problems in the very behavior of messy humans themselves.

Bonus Paragraph: How to Read!

You, of course, know how to read. I get that. But reading work by professional research scholars — even books intended for a popular audience, as are many of these — is a bit different from reading professional or trade publications. As a grad student (in English, during which time I read a lot), I developed some habits to help me better understand, retain, synthesize, and be able to recall texts like these. Here’s what worked for me:

1. Buy a Book

If I’m going to read a book like one of those listed here, I want a paper copy I can write in and (slightly) abuse. The point of a physical book for me is to be able to read it actively: underline, highlight, star passages, dog-ear corners, make notes. Reading actively helps you 1) integrate what you’re reading and synthesize it with the other ideas jumbling around in your head and 2) come back to this text weeks, months, or years later and quickly find the ideas and passages that piqued your interest.

2. Buy a Pencil

Leave it in the book. If you don’t have a pencil, you won’t take notes and you won’t annotate. You’ll read passively. Set yourself up to be an active, physically engaged reader. I like a mechanical pencil like these because they’re cheap, always sharp, fit well in a book, and allow me to write satanically tiny notes.

3. Steal a Sheet of Paper

Cut it in half, then fold one of your halves in half to make a booklet. Jot down the ideas and passages that stand out. I include page numbers so I can easily find passages later on. You’ll have to write small — and you’ll have to be selective about what you record (which is a good thing: too much note taking will slow you way down). Leave your notes in the book. Now when you come back and look for that idea or passage later, you’ll have both your annotations and a quick reference guide to the passages you personally found most intriguing.

This post was originally published at andyfitzgerald.org. If you’re interested in how cognitive science, language, and meaning-making fit in with the practice of user experience architecture & design, do check it out.

The Danger of Stopping at Z: Why Kids Should Code, in the Words of Dr. Seuss

freeCodeCamp — Thu, 16 Jun 2016 01:20:31 +0000

By William Cabell

“In the places I go there are things that I see

That I never could spell if I stopped with the Z.

I’m telling you this ‘cause you’re one of my friends.

My alphabet starts where your alphabet ends!”

So begins the journey of Conrad Cornelius o’Donald o’Dell into the world of code, the alphabet beyond the alphabet. Written in 1955, there is no direct mention of programming in Dr. Seuss’ On Beyond Zebra, of course, but it is clear in its message that staying locked within comfortable knowledge is a recipe for a boring and unfulfilled life.

As a universal message, this is one for academics, scientists, writers, and everyone else whose job involves expanding their understanding of the world. I heartily recommend the book to these people, but today, I’m recommending it to developers and technologists as well.

Read it with your children. Discuss with them the importance of exploration. But in particular, make clear the parallels with what you do as a hobby, for a living, or for a passion. Not only will it pay dividends for decades to come, but it will help to build a healthy respect for the utility of technology and the beauty of the humanities.

What On Beyond Zebra is about

For those of you who have not had the pleasure — or need a refresher — On Beyond Zebra relates the story of young Conrad Cornelius o’Donald o’Dell discovering a new branch of knowledge through the Narrator’s cavalier assertion that he would never be so boring as to stop at “Z” when he had reached the “end” of the alphabet.

The Narrator explains that there are letters beyond “Z,” which allow one to spell the sorts of words that one finds in Dr. Seuss’ books, such as Glikker and Floob-Boober-Bab-Boober-Bubs.

As the narrator drags Conrad from imaginary land to imaginary land, he shows him the incredible beasts and contraptions that they would have missed without the letters Glikk and Floob and more. After all this, the Narrator leaves Conrad back at the school’s blackboard where he found him, inventing his own new letter, A-Z erased and left long behind.

The other day, I looked in the rear-view mirror on the way to karate and asked my almost-five-year-old daughter if she knew what I was doing on my computer when I worked at home. She shrugged and said no. I decided it was time to tell her anyway.

I am in the midst of a major undertaking: learning to code from scratch, having not touched a computer in that way since I endured a QuickBasic class in middle school.

Starting with HTML5 and CSS, I am working my way through JavaScript, and plan to finish the rest of Free Code Camp’s Full Stack Development certification.

By training, though, I am an historian and a Classicist, meaning that, though I have never directly made money with what I learned in school, I find pleasure in drawing together disparate pieces of information and seeing how they inform each other.

So when I read this story of a boy who has his whole world opened up past its previous boundaries, I had an instant flashback to the first time that I wrote a piece of basic HTML and refreshed my browser to see an incarnation of that code appear there as if by magic, somehow transformed from the obtuse, alchemical equation in my text editor to the beautiful (to me), clean text, images, and links that now sat before me in shining Chrome.

How sad it would have been, to have missed that moment, just because my world was never expanded beyond the everyday constraints of A-Z to the new, exotic letters of and

. And then, how could I not think of my two young daughters and want to give them the power, as early as possible, to write their own thoughts and bring their own ideas into the world?

I sat down and read them On Beyond Zebra on a rainy afternoon in June. We had gotten it from the library on a whim, since we had already read through most of the Seuss canon, because as a parent, most children’s books are honestly not that fun to read, but the good Doctor’s are.

As we made our way through, enjoying the wordplay, rhythm, and meter (me) and striking illustrations (my daughters), I began to see a razor sharp argument for teaching children that there are always new fields of study and new worlds that lie beyond their current knowledge. And that is when I made the connection to code.

As our children grow and technology becomes increasingly unavoidable, it becomes essential to ensure that they inherit the digital world with open eyes and full understanding. They must not only understand on an intellectual level that they can push the envelope forward into unexplored territories, but also on a practical level know how to use the technologies that make this possible.

The danger comes when they approach technology simply as magic — not as a complicated, incredible ecosystem that is driven by the interplay of hardware and software. If we can stave off the lazy assumption of magic, our children can live more productive, interconnected, and ultimately, safer lives.

The talk

“Well, would you like to know what I’m doing?”

“Sure.”

“You know when we read the Fancy Nancy books, and there is one person who writes the words that we read and one person who draws the pictures that we look at?”

“Yeah.”

“You know those apps that you play on my phone or mommy’s phone? Or on an iPad? Like Toca House?”

“Yup.”

“Well, it’s a similar idea. There are people who draw all the pictures you see and touch, but then there are also people who write the languages that make those pictures move, or something happen when you touch the screen. And that’s what I’m doing. I’m not really even working yet, it’s more like I’m in school, learning those languages so I can write apps like that.”

Silence.

“Does that make sense?”

“Yes. Can I have a pretzel?”

“Yes, but only one, it’s almost time for dinner.”

For an almost-five-year-old, I’ll count that as a win.

Learning (and teaching) the new literacy

Coding is the new literacy. Software is seeping into every corner of our lives — often much faster than we as a culture can appreciate. The way that we communicate with machines, and the way those machines connect us to other people, is becoming increasingly vital.

There have been initiatives to help our children come through the education system having a better understanding of the STEM (Science Technology Engineering and Math) disciplines, and many universities have worked to expand those departments, sometimes at the expense of other “less profitable” ones.

I find the hubris in the “technology-first” movement terrifying, as it could mean a loss of the culture that has led us to where we are today. And this is where I found inspiration in a children’s book from 1955.

The beauty of children’s literature is its simplicity. At their best, children’s books read like good code. They take a concept, an idea, an entire worldview, and they present it in a way that is clean and clear and simple.

And much of that beauty is how, within a constrained vocabulary, those ideas shine through and spark something in every mind — whether young or old — and inspire comprehension and creativity.

This is where our children need to understand that with code, as with the “everyday” letters of A-Z, they can create any world in their imagination. They can solve any problem, and enact their wills upon the world in breathtaking way.

Software serves as the raw material of the future. Creativity will shape it into something that isn’t just functional, but beautiful. Thus, the liberal arts are a key component for helping children grow up to be healthy, sane members of society who can engage culture and society as intelligently as they engage problem solving, and the next wave of technology that stands poised to wash over us.

Don’t stop at Z

I haven’t yet started a follow-up to the conversation with my daughter, but I know now that continuing to educate her and her sister on what is happening when I’m on my computer with those funny symbols and words is going to be as important as any language. In the meantime, I will continue to read them as many Dr. Seuss and other books as I can, to ensure that when they start interacting with technology, they have the intellect and vocabulary to understand it.

While the narrator never looks down on Conrad for learning the alphabet, he’s clear in his astonishment that Conrad would have thought it acceptable to stop at “Z.” And so, the book and the subsequent conversation with my daughter became the inspiration for this article, and also for my new blog “On Beyond Z”which will focus on providing resources to help expose children to the worlds beyond our basic alphabet.

I aim to be a resource for parents and educators to help children find their way through this brave new world, so that the coming generations will be the first where significant portions of the population will grow up knowing the basics of programming as well as all of the cultural touchstones that shape our society.

And, even if technology wasn’t what he had in mind, Dr. Seuss was an advocate for helping children break out of the bounds of the A-Z alphabet and find their own way into the future.

What else is education for, if not to expand the mind to new possibilities, across all spectra?

As Dr. Seuss says:

“I led him around and I tried hard to show

There are things beyond Z that most people don’t know.

I took him past Zebra. As far as I could.

And I think, perhaps, maybe I did him some good…”

If you enjoyed this, please favorite and recommend below by clicking the ❤️! Thank you and check back weekly for more posts.

books - freeCodeCamp.org

What I Learned from The Pragmatic Programmer and The Clean Coder

Table of Contents

How to Take Responsibility

Testing is Important

Teamwork Makes the Dream Work

How to Estimate

Tracer Bullet Development

How to Handle Pressure

The Importance of Refactoring

Main Differences Between These Books

Conclusion

Resources

460 Free Textbooks – Math, Science, and More [Online PDF for College and High School]

High School Textbook Categories

College Textbook Categories

High school Textbooks (90)

Math

Natural Sciences

Classical Novels

College TextBooks (370)

Computer Science

Engineering

Education

Math

Natural Sciences

Medicine

Social Sciences

Humanities

Business

Law

Journalism and Communication

Machine Learning Systems Book Recommendations – Learn How to Build and Understand ML Systems

#1 — Hands-On Machine Learning with Scikit-Learn, Keras and TensorFlow, 2nd Edition

#2 — Machine Learning Engineering

#3 — Practical Deep Learning for Cloud, Mobile, and Edge

#4 — Building Machine Learning Pipelines

Interesting Read of the Week

Read the article: Internal Combustion Engine by Bartosz Ciechanowski

Thanks for reading!

How to Write Your First Technical Book: Tools, Techniques, and Resources for First-time Developer Authors

Motivation

First Hurdle

The basics: VS Code

Second Hurdle

Ask the questions

My approach

Create a todo list

Tasks

Start Small but Do Start

Chronological Order

Chronicle of the book journey

The tools and resources I used

Writing

Editing

Formatting

Page breaks in the PDF

About Me Page

Thank You Page

Book Title and Sub-title

Designing the Book Cover

License

Publishing your book

Share your work

LinkedIn

Reddit

Twitter

Blogs

Conclusion

Final List of Tools I used

Thanks for Reading

Best Computer Programming Books to Help You Learn to Code

General

Algorithms

C-lang

Coding Interview

Java

JavaScript

Python

Soft Skills