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.
I was working with a programmer with a deep knowledge of a particular technology. However, after working with him for a couple of hours, I realized that he was not especially pragmatic.
As we approach software today, often through web or mobile applications, people generally appreciate the elegance of the interaction or lack thereof. But as software engineers know, there is a lot going on behind the scenes. Of course, with user interfaces for the masses becoming a necessity for modern applications, designers and more artistic–oriented folks have been contributing to the practice of software development. That leads to the question: Is software more of a science or an art?
Much of programming is writing code with an obvious solution, it’s being a code monkey. You lay things out, you move them around, you wire it up, but you don’t really need to stop and think. I’d estimate that everyone is about equally good at this. But some of the work is also spent solving problems you’ve never seen before. This is where bugs are introduced, bad decisions are made, schedules are thrown out, and things go wrong. These problems are the really defining part of being a great programmer.
After being heads down in the code for quite a while now, we decided to dedicate a little time to sharpening our writing skills. In the coming weeks you should see a number of contributions covering a wide variety of topics. We’ll kick things off today with a seemingly pedestrian subject: the naming classes, files, variables, packages, etc.