Get The FREE Learning AngularJS Newsletter

Since I like using AngularJS and the current client project and the last few client projects I’ve been on use AngularJS, I realized there may be others out there who want to start learning AngularJS or enhancing their current AngularJS web apps. So I started a newsletter where we post the newest books, tutorials, articles, modules and code libraries that AngularJS developers should check out.

Click here to start getting the newsletter!

You can click here to check out the Learning AngularJS Archives before you sign up.

Working Analog

http://calnewport.com/blog/2015/02/06/deep-habits-work-analog/

I find the experience of printing things out and putting them to paper really does help you focus on what’s important and it does remove distractions. Recently I had to do this with the JIRA tickets that I’m working on and I printed out roughly 11 of them. It let me sit away from the screen and think about how many tasks were actually involved in resolving those tickets.

I’ve also been living like it’s the late 2000s and using a Moleskine daily planner and a notebook for notes. I still rely on Evernote and Zendone, but I make sure there’s some kind of duplicate analog version for anything that’s important. The daily planner saved me when my phone battery died and it was the only place where I could see my todo list for the day. I didn’t get a phone charge for 3 hours and those 3 hours would have been wasted if not for the Moleskine.

While at home, working analog is nice too because you can curl up on a couch but, most important, you can dim the lights. The constant brightness of screens everywhere is tiring on the eyes and some days I want a complete break from the screen to rest my eyes.

Getting Started with Apache Cassandra

Originally posted on SourceContribute:

Apache Cassandra is a highly scalable NoSQL database. This video is a nice 30 min introduction on how it works and why it’s useful to know.

One of the beauties of free/open source is that it powers much of the world and much of the largest websites in the world. Facebook created the project and released the code because they know how valuable it is. One of the benefits of releasing Cassandra’s code as free/open source and making it free as in price is that developers can freely download the code and learn how to use Cassandra. While there are still no formal classes in college or university that teach Cassandra, your company can still find developers out there who have learned it because they spent their spare time learning how to use it. That’s not possible with proprietary packages that charge high license fees (student pricing doesn’t apply to…

View original 34 more words

The Software Estimation Struggle

Software estimation research is … improving estimation techniques so that sophisticated organizations can achieve project results +-5% of estimate results…

…the typical software organization is not struggling to improve its estimates from +-10% to +-5% accuracy. The typical software organization is struggling to avoid estimates that are incorrect by 100% or more.

— Steve McConnell, Software Estimation: Demystifying the Black Art

software-estimation-book-cover

Risk in software estimation

Plus-or-minus qualifiers. Use plus-or-minus style estimates to indicate both the amount and the direction of uncertainty in the estimate. Even when you have been forced into promising the software in an unrealistic time frame, you can let those around you know how risky the schedule is by presenting your estimates in plus-or-minus style. An estimate of 6 months, + ½ month, –½ month says that the estimate is quite precise and that there’s a good chance of meeting the estimate. An estimate of 6 months, + 3 months, –2 months says that the estimate isn’t very precise and that there’s less chance of meeting the estimate. An estimate of 6 months, + 6 months, –0 months says that the estimate is quite optimistic—probably unrealistic.

Steve McConnell, Rapid Development: Taming Wild Software Schedules

Grunt2Gulp.js update: on the way to handling yeoman-generated Gruntfiles

grunt2gulp-logoThe second ever issue filed for grunt2gulp.js was caused by a Yeoman-generated Gruntfile. It’s a complex file and that’s exactly what I wanted when I first created the project. The example Gruntfiles I came up with were hand-crafted and weren’t very complex.

In any case, grab the latest the copy from github, make sure you’ve done an npm install in your project and then run grunt2gulp.js on your Gruntfile.js.

You can generate API docs using jsdoc for grunt2gulp.

Please report any issues here. Leave any comments about how useful you’re finding this tool or if you’re sticking to Grunt or Gulp and why.

For debugging I’m finding node-inspector to be really awesome.

Three Reasons Why Your Software Is So Far Behind Schedule

Rudolf Olah:

Yes. Many times yes.

However, to give a more detailed answer and one issue…

The first reason is true. Technical debt can be measured in onboarding time. If you don’t have an up-to-date set of documentation describing how to get up and running and your system requires lots of extra twiddling and fiddling around, then you have a lot of technical debt. When you do onboard a new developer, make sure they fix some of that and simplify the process further. By the time you get to onboard employee M + N you should have less onboarding time and less technical debt.

As the article points out, if Facebook with so many complex systems and many projects can allow for real useful code to be deployed within a day, your less complex system with 1/100th of the servers and complexity should take a few hours to be setup and allow you to deploy useful code.

With respect to the second reason I agree that you should know what you’re testing and why, elaborate test suites indicate that you’re testing the wrong thing or your tests are brittle. For example, I had to write unit tests that mocked out 3 dependencies and had methods called “add” and “remove”. Guess what I was testing? That’s right, whether the class would add or remove the object to an array/list/some other data structure. It didn’t require any special business logic or require elaborate rules and conditionals, it was a straight addition or removal. My test was essential the same as a unit test for a linked list or array data structure’s insert/push/append/delete methods. Those kinds of tests can be safely removed.

The third reason I’m iffy on. On the one hand, yes it makes sense to use AWS or Google App Engine or some other cloud service. On the other hand, those can be expensive and sometimes there are laws in your country that require keeping data within the country. That leaves three options: expensive local cloud server, private servers (VPS or co-located), private cloud. In Canada our web hosting services are always more expensive, same with our domain registration. Both private co-located servers and a private cloud require maintenance and/or lots of cash. Some Canadian companies aren’t limited and can use AWS or Google App Engine…but they end up not using it to the maximum ability because the company introduces some other limitations that defeat the purpose of using cloud-based hosting such as not designing the architecture to be scalable to take advantage of the cloud. You can see this in consulting and contracting firms where every single project requires a separate server as if the client you’re working for can’t envision their website growing exponentially…how depressing.

Originally posted on TechCrunch:

When not opining here on TechCrunch I’m a software engineer for the fine folks at HappyFunCorp (1) and I’m occasionally called on to diagnose and fix projects that have gone horribly wrong (2). The more I do this, the more I notice commonalities among problem projects–“antipatterns,” if you will. Here I give you three more of my ongoing list of such. Names have been changed to protect the guilty.

1. Onboarding Time == Technical Debt

Technical debt is not always a bad thing, but if you accrue too much of it, it will kill you. When under schedule pressure, or when new devs keep coming onto and going off a project, people tend to build new software subsystems and connect them to the old ones Rube-Goldberg style, instead of doing it right. It’s like turning a family home into a cantilevered skyscraper one room at a…

View original 849 more words