Functional Programming is gaining traction in the industry. Conversations are happening in blogs, and on Twitter. It can be an intimidating endeavor to undertake, but it doesn't have to be.
Feedback from my Pluralsight course on the topic, user izzyS123 said
Thanks so much. I now finally understand functional programming.
Keep up the amazing work!"
Has there ever been a time where you got a bug report and you didn’t even know where to start? Have you ever felt overwhelmed with how code is behaving? You’re expecting one thing and it does the exact opposite? Situations like these can be some of the more frustrating aspects of software development. Solving problems is central to being a top-notch developer, it’s part of what separates the experts from the novices.
Over the years I’ve come to realize that problem solving isn’t always easy, but it can be broken down into some basic steps. These same steps were taught to me when I first learned physics, and have helped me solve numerous problems.
By the end of the talk, you’ll have a mental framework for solving problems, and you’ll get to see that framework in practice as we solve problems that have happened on real-life software projects.
In the 1850s, a major cholera outbreak in London changed the course of medicine. In 1986, the Challenger exploded live on TV. Both of these events have lessons that we, as software developers, need to learn and incorporate in our professional lives.
In this talk, we’ll look at two different events that happened in two different professions and see parallels with our own profession. For example, how do you handle the push to get “that one last feature” in before the release? How do you approach a situation in which a critical bug is about to be released and nobody cares? We’ll explore those topics and more as we look at professionalism in the software community.
I used to love development. Then, sometime after I started doing it professionally, it really started to ware on me. I had days or weeks where I dreaded coming to the office. After all, I knew what I was going to find there. Bug reports from customers that would force me to dig deep into the bowels of the application, make a change and hope that my fix worked. And really hope that it didn’t break anything else.
Whenever I read old code, I absolutely hated it. Especially if I was the one to write it. It would bring back vague memories of conversations we had about the feature, but they were vague. I wasn’t really sure what the code was supposed to be doing, and reading it didn’t always help.
Then I started practicing Test Driven Development, and it changed how I looked at my job and how I looked at my code. Now I enjoy coming in to work. I sometimes find it hard to leave because I’m making so much progress. I find myself having features and user stories just fly by, as I’m continually making progress towards the goal line. Even my code has become more readable.
In this talk, we’ll look at how it was that TDD was able to help me achieve that, how it can do it for you, and how, in the end, TDD is about much more than just testing.
In 2008 my mom was diagnosed with ALS. Over the next 18 months, ALS stole more and more abilities from my mom, including her ability to speak. But what ALS took, software was able to help restore.
While not everyone will receive an ALS diagnosis, most of us will interact with software on a regular basis. As a result, software engineers need to approach writing software with this in mind.
This talk explores the role of software engineering in human flourishing. You’ll learn how the software you write today impacts the lives of your users, and how you can make that better. You’ll also learn ways to improve interactions with your team, considering them not just as coworkers but also people.
When working with an API there's always so much to remember, such as any special API keys, different URLs for different environments, as well as the shape that each request should take. In this talk, you'll learn how Postman can help simplify working with an API. It allows you to use variables so that the same request works whether it's in the testing or staging environment. You'll also learn how you can create automated API tests so that you ensure your API doesn't break between releases. You'll even see how Postman simplifies writing documentation for your API, so that your users can have an up-to-date explanation of what your API is doing. By the end of this course, you'll know the ins and outs of Postman, and be equipped to maximize your interactions with APIs.
Creating meaningful unit tests can be a challenge. You not only need to figure out what needs to be tested, but you also have to figure out how to test it. You have to walk the delicate line of testing a specific case without making it so brittle that it easily breaks.
As challenging as writing unit tests can be, understanding them later can be even more difficult. The old adage that we read our code several times more than we write it hold true with unit tests.
Making unit test easier to write and easier to understand later don't have to be in conflict. At the end of the day, unit tests are just code. And just like other areas of your code there are patterns that you can use to help you simplify writing tests while also increasing readability.
By the end of this talk, you'll learn several various patterns and strategies for creating better unit tests. These patterns will not only ensure you're creating quality tests, but that you & your team can understand what you were testing when you read them later.
If you're like me, you've used several different front end frameworks such as Bootstrap, SemanticUI and others. You've enjoyed that they give you consistent components and layout.
But perhaps you've been frustrated by those same tools. It could be that every site you have created with them looks the same. Or maybe you've gotten into fights with your design team as they ask for a look and feel that is nearly impossible for you to pull off.
That was me until recently. Combining React, design systems and Storybook, my team and I were able to create our own component library from scratch, and it was easier than I could have imagined.
But more than just having our own framework, we found that our team was much more collaborative involving developers and designers as we created a custom UI for our client.
This talk walks through our experience, lessons learned, and highlights some tools and libraries that were essential in creating our own UI framework.
Creating and documenting UI patterns and functionality is often skipped on projects due to the effort required to keep the docs up to date. However, this kind of documentation is invaluable for project teams. In this talk you'll learn both how and why you would use Storybook. You'll also learn how and when to customize it to fit your team's needs.