Avoiding Difficult Errors

The errors do happen. It’s impossible to write error-free lines of code at first.

If it has to happen, then I would like it to be easily searchable, and have been happened to others, and publicly documented, preferably with right solutions.

Often errors are caused by attempting to do something new after learning about changes in methods, or when adopting external source codes.

However, the difficulty in fixing the errors may be eased, if your new attempts are based on rigorously reviewed official documents, or widely used & time-tested open sources. Unless, you were doing extremely strange stuff, most of the errors you will encounter usually already had happened to others, and fortunately solved and documented for you.

Or, if your error is absolutely new one, you have the right (or responsibility) to expose it and ask for attention from others. Because the error is caused by your attempts based on the official documents, there is no way fellow developers who read the same documents to ignore the situation. It does matter to them. And they will join you to fix the problem, making the process relatively easier than doing it alone.

If what makes fixing the errors difficult is because they are strange to you, and you have to do it by yourself, improving the condition of the root causes can help you avoid the difficult errors.

Advertisements

Can App PREview Process be helpful?

Recently, our team has submitted an iOS app to the App Store to be reviewed.

Unfortunately, due to Apple’s own policy, this app was rejected and we couldn’t release it.

Personally, I have known this would happen. What this app tried to do was something questionable, at least in its intention, even if there is no technical violation.

Our team’s strategy was very simple. If Apple didn’t publish anything against about what this app tried to do, we could challenge Apple to accept the end product. If Apple didn’t say NO publicly, we should try it. That was the argument of the team leader.

However, Apple’s decision after reviewing was solid and there is no way we can reclaim time we spent to develop this app. The only comfort we could get was that Apple’s reviewer himself also felt sorry for us, recognizing it’s not a technical violation but just a political issue.

I just wish we could have known about Apple’s policy on this long before designing and developing the app. At least for me, if I could present public documentation about this matter, maybe I could persuade the team leader not to waste our time.

Or, it could be so much better if there are people in Apple’s side, who may answer our questions, BEFORE we start designing & developing something. I wonder if it’s helpful to have PREview team, like REview team.

Of course, there are a lot of instructive materials, teaching us what should we consider when developing an iOS app. But I just wish there is an actual Apple Genius whom we can talk to about very special and rare idea of ours, we just can’t help but to try out.

It’s just wishful thinking of mine.

Learning to Adopt Concurrency with Confidence

Recently, I have been enjoying the opportunity to practice implementing concurrency in my software engineering.

Following iOS’s own concurrency programming guidelines, I could develop some confidence in designing the workflow from the initial stage to achieve optimal performance.

By separating works into two types; for UI & not for UI; I have been able to keep queues of operations to be as simple as possible. Also, due to obvious convenience of using Block programming with iOS SDK, I could be able to actually see where asynchronous queues branched out, and merged back, right within the scopes of codes.

Being able to keep tracks of these operations was quite exciting for me, since I used to have great fear in adopting concurrency. But the real issue I have to fear should have been lack of real performance and difficulty in seeing the workflows among the objects.

Fortunately, learning more about the convenience of using NSOperationQueue and the basic criteria for deciding when to branch out and when to merge back, which is; “Are these operations for UI or not?”, I could see what’s actually going on much clearer than ever.

It has been a good case for me to realize it’s not enough to memorize the list of methods, but often it’s more important to know when and where to use them appropriately.

PopToo is updated to version 1.3.5!

And changed its name to PopToo Classic.

[iTunes Link: http://itunes.com/apps/poptoo]

As a preparation for New PopToo, this Classic version has implemented potential iCloud functionality. It’s not yet operating, but next updates will bring ways to utilize iCloud storage, so you can migrate your history to New PopToo with no problem.

Currently, New PopToo is being developed by totally rewriting it. The main goals of New PopToo are:

  1. Focusing on Personal Use: Instead of requiring the user to connect to his or her social network to use PopToo, it will focus on being an utility which is great for geotagging user’s favorite music. Of course, sharing through social networks will not be gone, but be upgraded instead.
  2. Improved User Experience: New PopToo will be more handsome to look at, more interactive to touches. After all, iPhone and iPad has been touch centric devices and New PopToo will take more advantages of them.
  3. Adopting latest methodologies in iOS development: After being more informed about strong user acceptances in latest iOS versions in general, I am confident that us iOS developers are free from supporting legacy versions, and the cost of such freedom is tremendously inexpensive.
  4. Optimizing essential performances: The fundamental software problems including error handling, concurrent processing, and database architecting will be thoroughly revised. As a student of computer science, it’s my responsibility and privilege to look for the right solutions and learn to implement them to bring the best performance of PopToo.

By the way, I was able bought a ticket to WWDC 2012. It will be a great experience for me to be able learn new ideas and meet great people, I believe.

Enjoy PopTooing your favorite music!

Migrated to WordPress.com

My blog had been residing in a hosted server for a few years. Along with blogging, for the purpose of teaching myself how to develop in the generic PHP & MySQL environment, I had been using this service paying annual hosting fee.

However, due to the decrease of my interest in PHP development, and need to get deeper into Django or Rails, I decided to move my blog to the free WordPress.com hosting. And I may use the service fee I just saved for other types of hosting in the future.

Having a separate hosted service and being able to tinker with WordPress(PHP) and MySQL did teach me a lot about how to set up a website and manage it. But I think it’s time to move on and challenge myself to get into newer and more serious type of development for web applications.

Since my future plan has less to do with blogging, I think it will be sufficient enough for me to use free blogging services like WordPress.com. Who knows, maybe I get to like this service more than I imagined and subscribe to paid plan.

Do your best to spend time for the Real Work

Recently, I had to work so much time on one element of the product, requested by the colleague who was not completely sure if the application was perfect enough for her to think that the product was alright to be released.

At the end, we have found that perfecting the element was impossible since it relies on the external conditions like network status. I had known about this, but I had to show it to her to convince her that it was impossible. She usually don’t understand about software limitations without actually seeing them.

I don’t disrespect perfectionism. Sometimes, even I can see myself spending so much time for just a few things of whole product, to satisfy my purposes for them.

However, it’s false to consider getting the perfect result is directly related to and only possible by working a lot of time on it.

And if such hours were spent for the sake of reenacting already known and proven limitations, you should accept the fact that you just wasted precious time which could be spent for the real work.

I am trying my best to use my work hours for the real work. But it’s irritating when it’s not possible because of incompetencies of others.