This year I worked on a project which involved populating a huge HTML table (up to 1,048,576 rows by 16,384 columns) cell-by-cell, with data retrieved via ajax calls. Needless to say, performance was not good.
As a software consulting firm, Grio strives to provide high quality, high value software to its clients. We embrace an agile software development methodology based on Scrum. This iterative approach provides our clients with flexibility to adapt and change their product over the course of development as discoveries are made while using the software.
This flexibility can prove challenging when providing up front estimates regarding project costs. The problem arises that providing an estimate that is too high may lose you the contract; Estimating too low can result in several outcomes:
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.
Notifying users with quick messages and alerts in a website is one of the most recurring needs of a web developer.
Every time I need to implement something like that, I start looking around the web hoping to find some Javascript/jQuery plugin that would do the work for me.
The good thing is that a lot of people have already faced this problem.
The bad thing is that the results of the search are way too many and often very confusing.
Chances are that most of the time, you don’t really need a 3MB-super-fancy-hyper-customizable-highly-priced plugin, but you just want something that works, and that you can quickly incorporate into your code.
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.
Borrowing an idea from Jeff Atwood, here is a list of misconceptions about how Stack Overflow should be used that are common enough to warrant rote responses.
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?
Wrong!
See all the fun things that we do at Grio in addition to work.
When building an iOS application there are times when the best solution for a particular view or screen is to build it as a webpage and then embed it into the app using a UIWebView. There are certain things a webview can do really well that are otherwise hard to replicate, and while not as sexy, web development can be much quicker than native iOS development. The specifics of when to use a webview and when to go native I won’t dive into, but if you decide to use a webview, the first major question you’ll probably wonder is how to communicate between the native app and the webview. For full integration into the app, being able to send messages from the JavaScript to Objective-C and back is critical, and luckily it’s quite easy.