Constructing our next internal video game (Whack Attack) in the Unity software system has been a joyful experience and a return to my roots as a video game programmer. Instead of dealing with tables and lists for an enterprise web application, I find myself programming mole AI and hit reactions. As an internal project, the few hours a week I get to spend making cartoon mammals run around my phone are a welcome diversion, and makes my return to client work that much more satisfying.
As a recent convert to Test Driven Development (or TDD as his friends call him), I was surprised to hear that there were in fact 2 kinds of developer driven testing. The standard one that everyone knows of is unit testing: writing little testXXX methods that test a single publicly exposed method. But the lesser known – but just as important – are acceptance tests: tests which verify that a group of classes working together properly fulfill some functionality.
So this first post will take a closer look at the first type of testing, unit tests, and will go into the value it provides to you as a developer.
Meetings. When used correctly, they lead to synchronized teams, informed stakeholders, and better requirements. They help to identify issues affecting an organization. They’re great for resource planning, sharing vision, and all kinds of useful stuff.
A clear, focused meeting energizes the participants. These meetings are a force for good. These meetings make the office smile.
Then there are those other meetings.
If you’re like me, you probably do an increasing amount of your personal business on your mobile device, such as paying bills and conducting transactions with your banking accounts. And why not? It’s been five years now since the first iPhone came out, and since then mobile Internet use has become a part of everyday life. What’s more, major institutions such as Wells Fargo, Citibank and AT&T have their own mobile apps. So taking care of your financial business on your smartphone should be a complete breeze, right?
See all the fun things that we do at Grio in addition to work.
On larger Git projects, I often see the following scenario play out after someone’s done some work and is ready to push it to the remote repo:
...making and committing changes to "develop" branch...
$ git pull
$ git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 363 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
e8c1210..1a0c4d4 develop -> develop
! [rejected] new_feature -> new_feature (non-fast-forward)
error: failed to push some refs to 'email@example.com:test-repo/test_repo.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
In this week post I decided to do something a little different. Being a designer, I am used to drawing more than writing. So, here I am drawing. . . I hope you guys enjoy.