Categories: AngularJS, Portfolio, Software Development

Forget React, Learn AngularJS 2.0 with this video tutorial!

In the last few weeks I’ve been busy preparing AngularJS 2 courses and I’m really excited about the first video tutorial that NeverFriday Software Expertise is releasing.

1

In this tutorial you learn how to create an AngularJS 2.x project and how to create a comment box directive component. In the React tutorial, they show you how to create a comment box just like on Facebook so I thought, why not show how easily it can be done in AnagularJS 2?

And let me tell you, it was really easy. AngularJS 2 has all the same features you liked in AngularJS but it has a better structure and better modularity. I just made a giant list of differences between Angular 2 vs 1.

Learn AngularJS 2 and create a cool component in less than 30 minutes. Click here to buy the video (prices go up in November so buy it now!)

 

Categories: Portfolio, Software Development

Use JSON in Perl 6, article published

I wrote an article for codementor.io on how to use JSON in Perl 6.

It’s a good tutorial and introduction to Perl 6 which hasn’t seen wide adoption yet. It’s a solid language which has had a lot of thought put into it and the libraries that exist for it so far are good. Since it’s still Perl, it has that hack-y, fast-paced feel to it where you feel like you can quickly put together a one-off script to get the job done or put together an MVP (Minimal Viable Product). However, since Perl 6 is better designed, you can build a well-structured, well-engineered large project.

Learning new languages and how they work can help make you a better programmer and introduce new ways of thinking that can make it easier for you to find solutions to technical problems.

Categories: Leadership

How to apply cause and effect diagrams in IT and Software Development

Cause and effect diagrams, also known as Ishikawa diagrams, are one of 7 basic tools of quality. You won’t see them used very often in software development or IT projects though they should be. So today we’re going through what cause and effect diagrams are, why they’re useful, an example diagram, and case studies.
Continue reading “How to apply cause and effect diagrams in IT and Software Development”

Categories: Software Development

Django Unit Testing with Mocks

Here I’m going to talk about how to use mocks when writing unit tests for Django, the Python-based web framework. Using Django test mocks has really opened my eyes on how to write much better unit tests. Previously, and in some cases still do when using 3rd party services, I would use fake API servers to serve fake data for testing end to end. With the mock library, I can easily mock out server responses in Django tests.
Continue reading “Django Unit Testing with Mocks”

StackOverflow Search (SOS) mode for Emacs

Emacs Stack overflow: StackOverflow Search (SOS) mode for Emacs

I was reading about a PhD student who created a plugin for an IDE that integrates searching for questions & answers on a knowledge base that included an easy way to insert code snippets from the answers in their own source code.

I use stackoverflow as often as I can and try to contribute answers but sometimes I have questions of my own so it would be nice if there were a quick, integrated way of using StackOverflow from within Emacs.

Type in M-x sos and then type in your search and the results are listed using org-mode. Eventually I want to be able to ask questions from within emacs and allow question buffers to be opened that are refreshed once in a while to see if there’s an answer yet.

Emacs Stack overflow SOS mode
Emacs StackOverflow SOS Mode

Update July 2017: Extending Emacs and creating plugins for it to increase productivity is something I enjoy doing because the pay-off can be immense over time. I’ve done this for running PHPUnit unit tests from within Emacs, highlighting AngularJS JavaScript code with Emacs, and highlighting Flow type annotations with React.js’s JSX syntax.

PyCharm: Markdown mode can display a Preview

The PyCharm markdown mode can display a preview! PyCharm is an IDE based on the popular IntelliJ IDE, it is specifically designed for working with Python. On most projects, Markdown is the popular text format that is used. It can be helpful to see a preview of the Markdown text that you are writing before committing it to your code repository or wiki.

If you need more reasons to try PyCharm, check out my presentation “Why PyCharm?”

It’s something that will help me document projects. Sometimes I wonder how the README of a project will look on github or bitbucket and the only way for me to check is to push my changes, fire up the browser, go to the repo and check it out. If there’s a mistake, then I have to do another commit, reload the browser and see what happens.

Text mode:

Text view of markdown in PyCharm
Text view of markdown in PyCharm

Preview mode:

Preview of a markdown file in PyCharm
Preview of a markdown file in PyCharm
Categories: Portfolio, Software Development

Presentation: Why PyCharm

Just created a short presentation for work about why I’m checking out the PyCharm IDE.

I wrote an article about trying out PyCharm for Python development. I learned to use it when working with Django (though I have used Emacs for web development usually). PyCharm has a lot of advantages and what I like about it, and RubyMine, is that you can use Ctrl+Click (on GNU/Linux and Windows) or Command+Click (on Mac OS X) to see where a method or class is defined or to find where it is being used in the code base.

Update: found a nice post by a VIM user who switched to PyCharm and found it awesome how integrated everything is.

Categories: Leadership

Effective Technical Leadership

Some notes from the Effective Technical Leadership talk given by David Byttow.

Attributes of an effective technical lead

  • Knowledge: “A strong tech lead’s knowledge is broad and deep…A tech lead should be a master of several technologies.”
  • Speed: “be ultra-responsive and capable of making instant decisions, always kicking the ball forward”
  • Awareness: “You should be able to keep the current state of the entire project in your head at all times.”

Activities

Some key actions

  • Help create and stack rank project priorities
  • Define best practices for issue tracking
  • Coach other engineers
  • Review code in detail and provide useful feedback
  • Shield engineers from management when needed
  • Explain why decisions are made
  • Fight for the right design decisions
  • Load-balance work among the team

Generating a Culture of Code Documentation

Generating a Culture of Code Documentation

This is from a presentation given at the Write the Docs conference,

Cutter’s experience is that SMEs fall into three categories in roughly equal proportion: eager to help, willing to help (with guidance in the form of templates and direction), and curmudgeons.

…You as a writer have knowledge that engineers need to help them write docs effectively, and when you share that knowledge you help them write more docs. Hold doc office hours where you’re available to help them with docs. Because some text is better than no text.

Curmudgeons will say “but code documents itself!” Cutter calls “bull”; code only tells what it does, not its intent. [NB: Intent is worthless if the code’s action doesn’t match it.] Even if you know what you wrote immediately after you wrote it, six months later you’ll have moved on and that’s when the documentation becomes critical.

Alternatives to Acceptance Testing

Alternatives to Acceptance Testing

I like the goal of eliminating defects while you’re writing code rather than fix bugs later on.

When it comes to testing, my goal is to eliminate defects. At least the ones that matter. (Netscape 4.01 users, you’re on your own.) And I’d much rather prevent defects than find and fix them days or weeks later.

I think of defects as coming from four sources: programmer errors, design errors, requirements errors, and systemic errors. When trying to eliminate defects, I look for practices that address these four causes.

He lists some solid methods for preventing defects for each of these classes of errors.

Preventing programming errors is done with test-driven development; unit-tests, focused integration tests and end-to-end integration tests.

Preventing design errors is done by having a simple clean design, incrementally improving the design and architecture and constantly refactoring to ensure it continues to be clean.

Preventing requirements errors:

  • a whole team is required, cross-functional and able to get what they need to finish the project
  • customer examples, using multiple examples can help clarify the general idea of the feature to implement
  • customer review, get the programmers to walk through the new functionality with customer, kinda like the client UAT (User Acceptance Tests) we do at work.
  • push testers to help in the build process rather than relying on them after releases are made. They can work with the customer to figure out requirements or set up automated regression testing (most companies rely on manual regression testing which eats up a lot of time)

This whole article is very good and Mr Shore is an excellent writer. I’d recommend getting his book too, The Art of Agile Development.