The idea behind PopToo

GOAL
Augmenting Common Activity (Music Listening) with Associated Experience (Geo-social Interaction)

BACKGROUND (Reasoning)

1. People like to associate individual activity with the shared ideas like location and musical taste.
    e.g. Crowded concerts, Café playing music for customers

2. From this association, social interaction can happen.
    e.g. Making new friend because of being at the same place and liking the same kind of genre.

3. Such result of interaction is often actively pursued with expectation.
    e.g. Going to a place, or liking a genre, to make new friends.

4. This expectation has entertaining value, enough to encourage people to look for effective solutions.
    e.g. Reading a magazine promoting a Jazz bar playing only Jazz to have fun with new friends.
    e.g. Posting what song he or she just listened on Facebook and count how many Likes received.

• An effective solution can provide entertaining value to people.
• Social interaction should be expected from the effective solution.
• Associating music and location can generate social interaction.

People can get entertaining value from the effective solution for Augmenting Music Listening with Geo-social Interaction.
-> Augmented Music Listening with Geo-social Interaction can be an effective solution for entertaining value.

EMAIL UPDATE SIGN-UP: http://eepurl.com/F5YQP

Advertisement

[TED] Why privacy matters

http://www.ted.com/talks/glenn_greenwald_why_privacy_matters

[Security Now] iOS Security by Steve Gibson

Whenever I listen to @SGgrc‘s GREAT lecture, it’s hard to stay unimpressed.

Fully informed and experienced decision

My comment for “Why I Don’t Use Interface Builder”: http://blog.teamtreehouse.com/why-i-dont-use-interface-builder

IB is about Organizing, not about Replacing. IB is a tool, not a regulation.
Once you know the limits of IB and developed good programming habits, IB can be extremely useful.

I saw too much terrible spaghetti codes, which could have been helped by adopting MVC principles and knowing the life cycles of UIViewController & UIView instances.
As a way to help those developers to learn about the principles, I show them how to complete a project using IB and later replace it using only codes, to help them to realize the limits of XIB files and see how whole structure is preserved, to show the real reason for using IB: Separating codes.

And once VIEW components are separated from others, I point out patterns or repetition, which are just configurations at loading of the instances.
Other than iteration, they are not so easy to be solved creatively and quickly, without taking precious seconds, minutes, or hours.
Also, there are more important tasks for fulfilling the requirements of the app, than tasks for calculating frames for labels.

Unless you like it (I saw some people who like it), it’s smart or even necessary to use a tool which was developed to avoid working mechanically. Fortunately in Xcode, we have Interface Builder.

Depending on the characteristic of the projects, the decision to use or not to use IB is totally up to the developers. When they decide not to, I hope it’s fully informed and experienced one, instead of one caused by estranged or uncomfortable feeling toward IB.

Don’t punish Yourself

It’s given as a PUNISHMENT to a student to write sentences REPEATEDLY on a blackboard.

If you are not careful, it’s quite easy to REPEATEDLY paste copies of identical code snippets. Not using iterative methodologies and not trying to find algorithmic solutions, is like let yourself to be in the state of uncomfortable incompetency, which is a PUNISHMENT.

Sensitive Programmer

As a learner of programming, you may feel stressed and uncomfortable, trying your best to maintain control over the machine, not to be controlled by it.

There are too little time to complete the assignment. Your mind is not clear enough to come up with the best structure of different classes. Inheritance, polymorphism, DRY, MVC and all other essential concepts about quality programming are just ideas without visible lines of codes.

Even if you could finish your work on time, it’s quite painful to see resultant chaos in your own codes. You don’t like your own work, knowing every line in it. And this is a good thing.

Being sensitive enough to realize inefficiency and incompetency in your own work, even if no one criticize it, is a great attitude, especially if you are a beginner. Congratulation! Make sure to keep it as sensitive and sincere like that.

Until you become a true master of programming, who can bring undeniable great architectural solution without taking too much time and resources, please don’t try to avoid or ease the pain for producing quality result.

It’s necessary to feel the inefficiency of scattered snippets within your codes. You need to experience the frustration of attempting to change a small thing, repeatedly about thousand times. After experiencing this, you will never forget the critical importance of DRY principles and will force yourself to learn how to use global variables and methods, apply proper hierarchical relationship among classes. Soon, it will become natural to you as you become a better programmer.

However, it you let yourself to be insensitive to pain while programming; e.g. listening to music or copying & pasting mindlessly; you will lose the opportunity to see the need to improve. Simply for the sake of finishing the work as soon as possible, you will just pass by the situation which may teach you very important principles.

Such insensitivity will bite you back, as you maintain the chaotic structure, slavishly patching the effects without fixing the causes. And finally, you will give up, unless you can start all over again.

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.

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!

iOS Tech Talk 2011 in Seoul

[This blog does not contain any technical information. Also, I am an Apple fan, probably my blog will be purely subjective.]

Today, December 8, was very special day for me.

It was my birthday, which was meaningful to me and my parents.

Also, it was the event day for iOS Tech Talk in Seoul, which was meaningful to every iOS developer in S. Korea.

One of the greatest things I didn’t expect from this event was to be able to meet the same instructors who were at the WWDC. In other words, this Tech Talk event can be considered as the extension of WWDC, not the another kind.

To some people, including myself, these instructors are the Rock Stars. They were touring around the world to excite their fans. Some people took pictures with their stars. I didn’t do it because I thought it could be perceived as objectifying them, which could be impolite. However, I just hope I don’t regret not taking pictures with them, later.

Aside their professional authority in the field of software development, the instructors were extremely friendly. They were so generous enough to pay good attention to people they never met before, who kept asking annoying questions. Probably, it’s their job requirement as the  Apple Evangelists. However, it’s impossible to ignore but respect their effort.

This one day event did impress me a lot, strengthening my positive perception about Apple and its people. They do know how to make their fans happy.

Allow me to reuse the tweet I shared: With these enthusiastic, friendly and yet extremely professional masters, the future of Apple will stay to be bright, I think. Even if Steve is no longer with them, with us.

I definitely want to attend WWDC 2012. Not only because I am eager to learn new technologies, but also I want to continue the joyful conversation I was having with the masters. Now it’s clear to me that, everything about Apple has become very personal to me.