A tip for an English learner

One advice for an English learner: Please make sure you can spell words correctly, before worrying if you can pronounce them attractively.

People are quite forgiving when you make pronunciation mistakes as a foreigner, but not so much if you make critical spelling errors.

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.

Advertisement

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.

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.

[Korean] About my comment on the book, ‘Real iOS Programming without Interface Builder’

This is the comment I left at following URL: http://www.acornpub.co.kr/blog/406  ‘인터페이스 빌더 없이 하는 아이폰 리얼 프로그래밍’

It’s about questioning the intention of the book about doing iOS development WITHOUT using  Interface Builder. It’s written without reading the book yet.

I’m a strong proponent of Interface Builder and its usefulness, and my comment was about that not using the Interface Builder may not be useful for those who need to read this book, who may be new to programming. And ironically to the author’s intention, it may not be able to help creating the application which should be easily maintained and expanded.

(내용을 읽지 않고, 별도의 프로그래밍 관련 주제의 댓글입니다. 소개글만 읽고 적은 것이므로. 책에 대한 평가로 오해하지 말아주세요.)

좋은 책이 나온 것 같습니다. 인터페이스 빌더’만’ 쓸 줄 아시는 분들에게 무척이나 유용하고 의미있는 내용을 가지고 있을 것이라 생각됩니다.

정교하고 디테일한, 100% 통제를 해서 모든 요소들을 일일이 다 챙기는 것이 중요한 프로젝트라면 당연히 코딩으로 VIEW 또한 손수 다 그리는 것이 좋을 수 있습니다.
또한, .xib 은 일종의 XML 로서 parsing 과정을 거쳐야 하기 때문에, 0.001 초라도 아껴야하는 경우에는 분명 사용하지 않는 것이 맞습니다.

하지만, MVC 분리법에 대한 충분한 이해가 되지 않은 초보 개발자, 실제로 응용해본 경험이 적고, 그 가치를 제대로 이해하지 못한 개발자들에게는 잘못하면, VIEW-CONTROL-MODEL 에 속하는 코드들이 우후죽순 막 섞히는 결과물을 내게 만들기도 합니다. 마감날짜가 급한 경우에는 더더욱 유지보수에 문제가 있는 (앞으로 문제가 생길) ‘위험한 코드’를 만들게 되지요.

이렇게 되면 소개글에 나타난 대로 유지보수에 탁월한 해결책이 되어주지 못하게 됩니다.

분명 하드코딩은 중요하고, 어떤 개발환경도 반드시 이것을 가능케 해야 합니다. 하지만, 이것은 과거의 생산물이 가진 생명력을 연장하는데 좋은 것이지, 미래를 위한 혁신적인 결과물을 만드는데 장애가 되는 것이라 생각합니다.

그래서, 혹시라도 미래를 위해서 일해야할 초보 개발자들에게 잘못된 습관을 가지게 하거나 자칫 혼란을 주지 않을까 하네요. 컴퓨터가 할 수 있고, 컴퓨터가 해주는 것이 훨씬 더 좋은 일인데도 불구하고, 단지 자기는 이렇게 가르침 받았고, 이렇게 하고 싶다는 이유만으로 하드 코딩을 고집하는 것은 미래에 대한 좋은 준비자세가 아니라고 생각합니다.

또한 단지 코멘트를 많이 남기기 위해서도 좋은 이유라고 생각되지 않네요. 코멘트 대신에 코드 그 자체로 모든 내용을 표현할 수 있다면 제일 좋다고 많은 분들이 얘기하시는 것 같던데.

반대로, 인터페이스 빌더를 쓰면 그에 대한 설명을 구구절절 코멘트로 어딘가게 남겨둬야 하니, 아예 코멘트 없이 코딩을 하기 위해서라도 하드코딩을 하는게 좋다고 하려 하신 거라면, 적극 동감할 수는 있습니다.

책의 내용은 분명 추정컨데 회사내 베테랑 개발자들에게 무척이나 도움이 되겠지만, 책없이 공부할 줄 아시는 그분들에게 정작 책이 필요하지 않을 것도 같고요. 왜 그동안 이것을 공개적으로 다룬 책이 씌여지지 않았을 지 좀더 냉정한 고민을 하셨기를 바랍니다.

당연히 그런 고민을 하셨다면, 어떻게 하면, 인터페이스 빌더의 장점과 하드코딩의 장점을 융합해서 양쪽 모두가 가진 탁월함을 같이 쓸 수 있는 방법도 책에 써주셨을 거라 믿습니다.

이런 목적으로 두마리 토끼를 다 잡는데 유용한 내용을 쓰셨다면, 이런 책이 다른 곳도 아닌 한국에서 한글로 먼저 출간된 것에 엄청난 자부심을 느끼셔도 좋을 것 같습니다.

My understanding in naming a Class with Prefix

Many source codes, especially those which are written in kinds of C languages, almost always named their classes using prefix.

Intuitively, I adopted to use this way of naming, since many GOOD ones were written in this way. My usual way of learning is by imitating.

As I’ve gained more experience, it became obvious to me why it’s critically helpful for programming.

In my case, I care quite a lot how methods and variables are named. Nicely named ones can help understanding the workflow, minimizing any confusion, thus producing reliable lines of codes.

However, one must careful not to use same syntax for the name of class and instance of it, since it’s difficult to distinguish if one is meant for the instance or the class. It gets worse if the class name and the instance name are as common as something like ‘WebViewController.’

Since naming instances of class happens more often than naming a class, it’s better to name the class with less common way. To make it less common, one of the easiest way is to use a prefix, elongating it to be syntactically different. For example, by using prefixed, ‘FXDWebViewController’ for the class name, one can use ‘webViewController’ as a name for an instance.

Though this instance name is quite common, you can use it as often as possible, without causing the programmer to be confused and even preventing compile time or run-time errors, as long as they are separated by scopes.

It gets even better when one has to use Find and Replace function, since syntactically different words are much easier to be found more quickly.

Also, using the prefix, you can leave it as some kind of signature, claiming your authorship and responsibility on the source codes.

Coding while Commuting

Last week, I’ve been coding while commuting to my office. Due to busy schedule for our projects, being required to learn Cocos2d framework, and having own desire to utilize my time to its fullest, I began to train myself to be more comfortable at coding while commuting using bus.

from New York Times

I use long distance bus from my home to subway station, and take a train to the office. It takes about an hour for bus ride and about 20 minutes for subway transit. And almost every time, I’ve been able to take a sit in the bus. In other words, I have an hour at my disposal to do something productive, such as coding.

Typing and building using Xcode works just fine, especially if you are free from needing to use big external display, comfortable desk and chair. When I do occasionally need to use internet, my iPhone 4 can provide personal hotspot. However, coding without internet browsing is not bad at all for me, since it lasts only about an hour.

During this hour of coding, somehow I could be able to focus on my coding more efficiently than while sitting  comfortably in my office. I suspect it’s because of using only Xcode with all other apps being closed, and encouraging myself to find solutions from my own stuff, rather than passively search answers from internet. Also, knowing the bus ride would last only for an hour, I could just focus on finishing miniscule but important matters which could be fixed quickly.

Because of this good experience, I began to have stronger desire to get Macbook Air. This lightweight compact laptop will surely make my coding while commuting more enjoyable, though my current 13″ Macbook Pro is not so bad at all. Guess I need to find about opinions of the developers using Macbook Air with Xcode, and how to deal with disadvantages.

Why having personal projects is critical for a software developer?

I would like to share my reasons, based on what I learned from other developers, to have personal projects outside of professional jobs.

Unless you are a super genius, who can implement newly acquired knowledge flawlessly at once, it’s inevitable to make mistakes in programming based on new ideas. Your choice for solutions will need to be revised repeatedly. It may require number of customizations to accommodate merging these solution with codes from other developers or from older projects, though they are working just fine with no problems by themselves.

At early stage, your professional job will provide this kind of challenges many times, allowing you to grow patience in dealing with errors and testing implementations to find the right solutions. Sooner or later, you may find yourself simply customizing lines of codes for already solved problems. In other words, your job will get easier as your professional experience grows.

Unlike many other professional fields, new technologies are introduced so often, much faster than we can keep up with. But until your project manager or supervising developer decides to use these new technologies, you may only hear about them, if this is the worst case.

Your ability to implement new ideas, that you’ve practiced so hard, will become dull or inefficient. And what makes it more depressing is that this kind of backsliding happens very quickly and drastically. When finally new technologies are required for your projects, it could be embarrassing that your development skill is much like how it were at the early stage of your profession.

Having your personal projects not only mean that you build something, but also that you make own decisions. Because you are in charge, you can test your implementation skill with new technologies without waiting for anything. Whether your attempt to use new ideas is successful or not, you will be prepared to deal with issues later when it’s much needed for real jobs assigned by your employer.

Along with technical decisions, you can also make scheduling one on your own, without any constraints. Of course, once it’s public and used by many others, you may have to listen to their requests and satisfy their demands as soon as possible. However, it’s done proactively, being able to lengthen or even shorten the development time as you like. This sense of controlling time is probably only possible if you have complete ownership of your project, which is by having personal project outside of your job.

Also, no matter how much dedication you’ve put into your works, technically these jobs assigned by your employer are actually not yours. These useful evidences for proving your skills may not be permitted to be used when you are applying for a new job from another company. But with you own personal projects, you can just submit them to be fully analyzed without any guilt but with great confidence. It’s always better to silently show what you are so good at, than just loudly speak about it.