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.
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?
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.
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.
You will learn:
What a cause and effect diagram is
The usefulness of cause and effect diagrams
Using industry-wide common causes as a starting point
Example cause and effect diagrams
Case studies, example cause explorations based on real-world experience
Applying cause and effect diagrams, applications of the diagrams to explore root causes
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”
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.
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.
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.
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.
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)