In the out and about section of this blog Mathemagics gets a good mention on the popular Games Keys website as a hand picked family app.

You can check it out here.

I’ve been hard at work the past few months working on a new app. This one is geared towards a younger audience and a more basic level of math. More details soon but for now check out this teaser video.

 

Math Facts is in beta now. If you’d like to help us test it and possibly get a free version of the app Apply Now.

I’m a fanatic about fixing warnings and errors in my code. Whenever I see one I tend to fix it right away which helps make it easy to see new ones when they pop up. However, there are occasions when you just can’t fix them. For instance, you might be using an open source bit of code without the time, knowledge, or commit access to fix a warning. In such cases a lot of warnings in a foreign piece of code can make your own hard to find due to the deluge of yellow icons all over the place. Well, fear not. There is a way to turn off warnings on a per file basis in Xcode.

 

 

Turning off warnings on a per file basis is super simple. All that is required is a compiler flag. Here’s the step by step process.

1. Open the Project Navigator in Xcode
2. Click on the Project icon at the very top of the navigator
3. In the resulting detail pane select the target that you are working with
4. Select “Build Phases”
5. Expand “Compile Sources”
6. In the list locate the file that you’re interested in
7. Double click the column under the “Compiler Flags” column next to your file
8. Add a -w to the resulting dialog
9. Click “Done”
10. Build your now warnings free project

Compiler Flags are extremely useful in certain situations. Not least among these is turning off ARC on a per file basis. To do so for a file simply add the -fno-objc-arc compiler flag.

Do note that suppressing warnings in your code base should be used judiciously. Be sure that you have a very good reason for doing so. With great power comes great responsibility.

 

It’s that time of year again when 148Apps and users select the Best App Ever. Mathemagics was a finalist in 2009. The app has improved tremendously since then and we’d love to make it to the top of the heap this time around. Below are a few categories that we have been nominated in. Click one of the links to cast your vote for Mathemagics in one of the following categories.

Best High School Student App

Best College Student App

Best Adult Education App

To vote simply click one of the links above and then click the big orange “Nominate this app” button on the resulting page. That’s it.

Thanks for your vote of support!

Developing software in a solo environment has its pros and cons. On the upside you have complete reign over the code base (no problems with ownership here), freedom to follow specific designs and an ability to express your creativity. On the other hand, the very nature of the activity can be your down fall; tunnel vision and shortsightedness can eclipse all of your efforts.

There is a way out of this quandary and its called peer review. The mere mention of “peer review” can strike fear and foreboding into the hearts of developers. But, like it or not, this egoless programming practice has the power to deliver.

Outside input can lead to an increase in production quality and ultimately product appeal. Here’s a few ways to get outside input and ideas if you’re flying solo:

• Direct communication with friends. Friends that you’ve made through previous jobs, ventures, or virtual contacts made real are great sources of input. When in the same industry they can provide a unique perspective. If it has been a longtime since you’ve touched base then invite them out for lunch, or better yet a beer, in order to reconnect.
• End Users. The end users of your product are an extremely valuable source of feedback. While a user may not be privy to the nitty gritty code details they will have an opinion about what is good or bad about your interface. Running a public or private beta will give you the chance to gather valuable feedback and roll it into a product before going live with it. For iPhone development take a look at TestFlight which is an awesome service for distributing beta builds and getting feedback from your test team.
• User groups. There is a good chance that there is a Cocoa developer group that meets regularly in your area. A few places to start would be CocoaHeads, NSCoder Night, and if you’re in Austin CocoaCoder. Getting out and mingling with other developers is a great way to cultivate ideas, get feedback and make a few friends. Try giving a short presentation to the group on some code or a technique that you’ve been working on. Not only will this give the group a chance to discuss a topic but it can help you validate ideas or to open up new avenues of thought.
• Virtual community. Participation in online forums, email lists, IRC channels, and of course blogs can be another source of outside input. While readily available the quality of this sort of feedback can tend towards the inflammatory. Be sure to research your questions and always interact per the guidelines of your chosen group. Oh, and be sure to don your flame retardant suit before dipping your toes in.

Whatever avenue you pursue to gain outside input it has the ability to not only improve on your own designs but to also increase your creativity. New ideas yield more new ideas and so on. So, if you’re feeling like you’ve hit a brick wall or that you need a second opinion try getting some outside input.

There used to be a senior exec in a company that I worked for who liked to say, “Feedback is the breakfast of champions”. Visuals from a literal translation of that Ken Blanchard quote aside, it has the power to transform anything. Feedback, in all of its forms, is often a tough serving to consume but a good helping of the right sort can push you beyond current limits and plateaus.

The Good,

When I think of that quote I imagine what kind of feedback the exec was talking about. For me it meant feedback from peers and end users. Depending on the crowd that you hang out with it can actually be quite difficult to get good constructive criticism. I know, I know, what you’re thinking. This guy is asking for it? Yea, as long as it contains that operative word constructive and is meant with sincerity. Feedback is often the only way for you to see beyond your own narrow view of the world. Think of the Truman Show. Here you have this guy who has known nothing else but a little island for his entire life. Then little by little he starts to notice inconsistencies which make him think about the world around him. Had those quirks never happened or had he failed to notice them he would still be sitting there on his TV show. Feedback is the express train to realization.

Constructive criticism coming from your peers can take you to new levels of your craft. Of course, it’s up to you to decide if any one piece of feedback takes you in the direction you want to go as a developer, individual, astronaut, or whatever. This requires some introspection on your part. Developing a bit of a rhinoceros skin and a good humor about yourself also helps to digest the horse pill that can be peer feedback. However, the best peer feedback is often of the positive persuasion. A simple, “Good job” or “Man, that’s great” can do wonders to spur someone on in their current direction.

Assuming that you’re a software developer/publisher, you can have feedback from end users. Feedback of this sort can put greenbacks in your pocket book. When a user emails to notify you that there is a UI bug or that they don’t understand the usage of some feature it is your clue that something may be up. The same or similar item coming from two, three, or even more people should start to perk up your spider senses to a potential improvement in a design or work flow. Again, introspection is the order of the day when deciding if a request or issue falls along the direction and intent of your particular flavor of software.

the Bad,

Being the bearer of feedback can be just as tough as receiving it. That is, if your intent is to be constructive (and I hope that it is). Simply blurting out your observation of flaws comes across as strictly criticism and that’s bad. Instead, hold back the thought for a bit and think of ways to improve on the subject at hand. I mean, you see a flaw so you must have an idea of how things could be better. Right? Reverse roles with the person and think about how you would want to hear the news that you are about to deliver. Finally, provide your critique along with a suggestion on how to improve. Running through this sequence becomes second nature once practiced for a while. Some people will do it naturally and don’t even think about it. Others need a process to follow. Some characteristics of good feedback include:

• Transfer of information rather than the giving of advise
• Covers a specific issue rather than a general one
• Focuses on the content rather than the person
• Offered with empathy

Just as bad as not being able to take feedback is never giving it. Floating merrily along accepting the status quo lies in a direct line towards failure. Yours or someone else’s. It could take years or even decades to materialize but sooner or later such a static nature will break down. Often an unwillingness to provide feedback is really masking a desire to avoid receiving it. If that’s you then start small. Give yourself time to develop the skills of giving and receiving feedback. I think you’ll be better for it in the long run.

and the Ugly

Trolls and flame warriors need not apply. We all know the type of inflammatory feedback that a supposedly anonymous internet can elicit. There is something about the feeling of anonymity that can draw out some of the more basal aspects of human nature. In short, there is little you can do but surround yourself with as many upstanding people as possible and simply ignore the occasional flame. Responding to outright deleterious comments or feedback usually only fans the flames and invites more of the same. Use that rhinoceros skin and good humor to the best of your ability and ignore it.

That’s a wrap

There you have it. The good, the bad, and the ugly of feedback. Sometimes it takes stepping outside of yourself in order to see the larger picture but feedback is a great way to grow an idea, a product, or yourself.

Feedback. It’s not just for breakfast anymore.

---

Note: This is a repost from my personal blog at http://shanecrawford.org

Visionary.

Creative Genius.

Rebel.

Human Being.

 

Thanks Steve.

Did you make a small improvement in some area of your apps today? Your design? Your business? Practice Kaizen and you would have. Kaizen is a Japanese philosophy for continuous improvement which has been applied to fields as varied as manufacturing and game development. While the philosophy includes making changes and adjusting based on their outcome one of the more useful aspects is improvement by continually making small changes.

Toyota famously uses this technique to increase manufacturing efficiency and productivity. Every worker is empowered to stop their production line suggest an improvement and work it into their larger process. They have formalized the process and made it a part of their corporate culture. Small changes made continually have led to a power house of manufacturing.

I think that Apple also uses a form of Kaizen. We all know that Apple makes incredible products and is known for innovation. But, they are not always first to market. Nor are many of their products initially released with the ultimate feature set. They have an innate knack for launching a product with the right feature set and then rapidly and continually improving it over time. All informed by a philosophy of simplicity and elegance. In fact, they are relentless about improvement even to the point of radically changing established and accepted products. Remember the very first iPod? It was a clunky device by todays standards. It also wasn’t the first nor the best digital music player of its day. But, it soon became the dominating music player as a result of relentlessly improving the device.

It’s amazing how quickly a group of small changes can result in a large one. By continually making small improvements you can quickly outpace competitors, increase end user satisfaction and create a product that is established in its niche. This technique is especially powerful when used by small teams or solo developers who can move nimbly but lack the resources of a larger outfit. Be relentless in your small but continual improvements and others will wonder how you get so much done. One brick at a time, that’s how. Add the philosophy of Kaizen to your mindset and make at least a small improvement in your app or business each and every day. Down the road you’ll be glad you did.

There has been some discussion recently on Twitter regarding developing from multiple machines. I work this way and it can be liberating. While in the office I typically work from a Mac Pro with a 27″ display. Ah, screen real-estate. But, I like to be mobile so I also work from a 15″ Mac Book Pro. When I’m ready to head out of the office for a while the last thing that I want is to worry about setting up my dev environment. I just want to grab the laptop and sprint out the door. Likewise when I return I want everything ready to go on the desktop. Keeping development environments synced between the two can be a real pain. That is unless you make use of “the cloud”.

 

 

I can hear you asking, “Isn’t this what version control systems are for?”. Yes. I am a big fan of version control and have used numerous systems over the years. Currently I use Git. I love the fact that I don’t need to be connected in order to work against the repo like I do with Subversion or Perforce. In addition, I think that the self contained nature of Git lends itself to this type of setup. I’m not so sure that a system like Perforce would fair so well. In a team environment version control is a no questions asked must have. In fact you should always use version control, even if you work solo like I do.

However, in order to keep everything in sync between machines I use Dropbox. Everything goes into the Dropbox folder. Source code, assets, Git repos, project files. The whole enchilada. Everything except for build directories which are regenerated with a simple build. The size of your project, especially assets, can be an issue when syncing over a slow network so keep that in mind. Fortunately, if both machines are on the same network then Dropbox will detect it and use the LAN Sync feature which will sync files over your local network vs the cloud. Unless you don’t have much code or you have managed to max out your referrals with Dropbox you’ll probably need to spring for one of the paid plans. Typically I like to keep all of my projects under a single top level directory. But, I like to keep that directory in my user space. As such I had a major aversion to moving everything over to the Dropbox folder. A simple symlink from the Dropbox folder to my preferred space solved that issue.

I’ve run into two caveats with this rather simplistic setup. First is not to have the same project open under Xcode at the same time on different machines. Otherwise strange and potentially harmful behaviors can and do occur. This means that when I leave the house I need to be sure that Xcode on the desktop is shutdown and vice versa. A small but important point. Second, remember that everything is synced immediately all of the time. So, if I’m working on a large Photoshop file, for example, from a coffee shop with a slow connection this could be an issue (especially with a severe -S habit). In such a case I might temporarily turn off Dropbox syncing until I can get to a faster network or back to HQ. Not ideal but I’m usually working on source files which sync quickly. If you desire more control over what is synced and when then this Stackoverflow post outlines a way to use Dropbox as a Git bare repo rather than just going all in on the syncing fire hose. Additionally, you may want to disable Growl notifications for Dropbox since they can get annoying after a while. There have also been some recent security concerns with Dropbox. I suppose that your level of trust in them and your comfort level with others potentially seeing your code will dictate whether or not you use a setup like this. For me the benefits outweigh the downside.

Even with a great automatic code syncing environment in the cloud you shouldn’t rely on it as your sole source of backup. Keep using your version control systems hopefully hosting offsite somewhere. I also use the great online backup utility Arq to regularly backup my important files including my development environment. In addition, I periodically create a sparse image of my entire hard drive using SuperDuper. That’s at least four copies of my code three of which are offsite. There is also a copy on my alternate machine ready to go. I sleep pretty well at night.

Xcode 4 has brought major changes but one of my favorites are the built in code snippets (maybe I’ll share mine sometime). However, there is no built in way to sync them between machines which can be frustrating and a major hassle when using a setup like this one. If you run into this then xcodesnippets is for you. It’s a simple ruby gem which packages up and organizes your snippets for easy transport to other machines. Unfortunately, there is no online syncing built in so you need to copy the snippet bundles over manually but otherwise it works great. It does seem however that using the magic of symlinks and Dropbox you might be able to setup some auto syncing of snippets even without such a tool. If you try this then please let us know how it works out.

I love the ability to run out the door with my laptop in hand without having to worry about having everything ready to go. It is. Likewise when I’m in the office I love being able to fire up Xcode on the Mac Pro and get to work immediately. As developers we spend all day in our environment and as such it is a very personal thing. So, this type of a setup may or may not work for you. Whichever the case please share your experiences and what works in your world.

Happy coding.