Wednesday, May 6, 2015

Adventures with RAC 3.0 and Swift 1.2

Last week I learnt about functional reactive programming concepts on iOS and I fell in love with the ideas <3

I read a couple of tutorials and Ash Furrow's Functional Reactive Programming on iOS book. I really liked the blog posts & tutorials of Colin Eberhardt. His teaching style is very neat and works well for me - cheers Colin! Ash Furrow's book is also very compact and his coding examples make things easier to grasp.

Functional reactive is one of the concepts which makes me feel so happy and excited after learning and can't wait to get my hands on it. So, this week I'll begin implementing a project of mine using ReactiveCocoa and Swift. This will be my first RAC and first Swift app, so a good mixture of pain and joy is waiting for me :)

ReactiveCocoa team is working on a new Swift API of RAC - RAC 3. Currently this is in beta and as of today v3.0-beta.3 is released. I wasn't sure whether to use RAC 2 with Swift or dive headfirst into RAC 3.0. There are many learning sources for RAC 2 but since RAC 3 is still in beta, the best source of information is their Github repo itself and a few blog posts from Colin again and Alexandros Salazar. The RAC 3 framework has a real steep learning curve and although the concepts are the same in 2 and 3, RAC 3's implementation is quite different and exploring the API is kind of difficult. But my teammate and I are feeling adventurous \o/ so we decided to get started with RAC 3.0 beta.

Here I want to share the information sources I could come up, as they're really rare at this moment.

Apart from keeping your eyes open on your RSS feed for upcoming blog posts:

  • On ReactiveCocoa's GitHub repo, go to issues and filter them using milestone:3.0 label:question. This will list the questions others have asked in the past and your question will probably be there.
  • Similar to above, filter the issues using label:"help wanted" milestone:3.0 This filter will return more noisy results as this label is used by the framework developers to request help from each other, too.
  • I'm usually having trouble to figure out the intended usage of the new API. I just discovered that the test code of the framework would be a good place to take a look at how the developers are using the API. So, go to ReactiveCocoaTests and wander around.
  • ReactiveCocoa team has a Slack group - You can request an invitation and if you join, you can follow the recent news about the framework, get in touch with the community members, ask and answer some questions.  
Whenever I come across a good learning source, I'll add to this list. Until then I hope these will do fine o/

Monday, March 16, 2015

Women Techmakers

I attended the Women Techmakers events in Eskisehir and Istanbul in the past two weeks and it was a real fun experience. Although the event is organised and sponsored by Google, my talk was on Apple WatchKit - oops! But since these events aim to encourage women to be more engaged in tech and not promote a platform, this was not a concern.

I uploaded my talk's slides to Speaker Deck although there's not much text in them. I have a hard time trying to follow a speaker's talk if the slides contain a lot of text, so I wanted to spare my listeners some of this pain. Still, the slides can give a rough idea about the outline, so enjoy as you wish.

During the conferences, many female students wanted to talk to me about the hard points of being a female engineer / entrepreneur. I always tell people coming with the same question that I don't experience such a thing at all. I'm a strong believer of the idea that if you have confidence in yourself,  this will absolutely be felt by the others around you. If you're self confident and you really kick ass in your area, then I'm sure you won't face any discrimination just because you're a female. If you still face it, then you should just leave there because you shouldn't have anything to do with any people who don't value you enough. Let this be their loss and you'll surely find another place to work where you'll feel valuable.

Also I get angry when I hear a women developer group or something like that, defining the group as "Women trying to do a man's job". Why are you defining yourself over a nonsense argument like that in the first place? I mean why are you even mentioning this? Why can't you be just "women gathering around for coding and socializing"? These definitions are cultivating this discrimination issue more and more in my opinion.

So, I was saying that you need to be self confident in your skills in order to be comfortable in every environment you work. How can you achieve this? I think the road to self confidence is through deliberate practice. Be aware of the areas you feel you need to improve and practice deliberately. Create as much output as you can and try to share this to get feedback. Your outputs will encourage you more and you'll prove it to yourself that you can achieve new things. This will motivate you more and in turn you'll create more. In time, you'll know that you're a kick ass and the people around you will not afford to undervalue you just because of your gender.

Saturday, February 7, 2015

Discipline >> Motivation

I've read a great post about motivation vs. discipline and I'd like to share it with you here. What the author talks about is matching up with my experiences so well and I'm the living proof of the ideas behind. So, I'm sure this point of view can also help many others. 

The basic idea is, motivation is kind of hard to have at the beginning; it wears you out mentally. But by building habits and sticking to them, you cultivate discipline and when you accomplish what you want with discipline, the feeling at the end will bring you the motivation you were longing for. This motivation will encourage you more, and in turn you'll achieve more. So, instead of thinking of the end product as a prerequisite to begin, you can change your point of view and try to have discipline as your prerequisite. This will probably get you where you want to go and there you'll find motivation automatically. 

I better not paraphrase the post here because the author's writing style is kind of interesting and I recommend that you read the original piece and enjoy it. Here are some excerpts from it:

Successful completion of tasks brings about the inner states that chronic procrastinators think they need to initiate tasks in the first place.Put in simpler form, you don’t wait until you’re in olympic form to start training. You train to get into olympic form.
The proper question is “How do I make my feelings inconsequential and do the things I consciously want to do without being a little bitch about it?”. The point is to cut the link between feelings and actions, and do it anyway. You get to feel good and buzzed and energetic and eager afterwards.
There is another, practical problem with motivation. It has a tiny shelf life, and needs constant refreshing. ... By contrast, discipline is like an engine that, once kickstarted, actually supplies energy to the system.
Productivity has no requisite mental states. For consistent, long-term results, discipline trumps motivation, runs circles around it, bangs its mom and eats its lunch.   

So come on, all hands on deck!

Wednesday, January 28, 2015

How I use git branches and stay zen

I'm using git as my version control system for a client project that's been going on for a year now. During this time, the way how I use git branches evolved and I could come up with a system that made things very easy for me. When you're working on a client project - actually for every project -  it's pretty normal for priorities to change. When you start implementing a feature, you may need to pause it and start working on another feature which has become more important now. Another thing is, sometimes you're waiting for something from your client but your client is busy for some reason and cannot provide what you need. You may not want to sit idle until you get those, so you may want to continue on the lower priority feature until you get what you need. By the way, these are not extreme conditions, they happen most of the time. As a developer, since you need to stay sane, you should be ready with your systematic way and handle these situations with minimum amount of time and energy. First, let's think about what would happen if you don't have a systematic way. In this case, when you need to leave the current feature implementation and switch to working on another one, you may need to revert some things on your previous work. This would happen because you may not have finished them yet and you wouldn't want a half-working thing, or even though you've finished it, your client may not want to release them yet. So, you need a way to hide or undo-but-still-keep them. This would happen on the hot fix scenario, too. Suppose you're in the middle of implementing a feature but you need to fix an urgent bug on the production code. I'm sure you would be unhappy with the nasty effort of commenting out your currently unfinished work. 

Here's what I do for a more zen maintenance experience:
  • featureComplete branch: This branch contains the finished & tested implementations of features. When you checkout this branch, you can expect that what you get will be already tested and every feature is complete - no requirements are missing.
  • feature branches: When I start a new feature, I create a new branch off of featureComplete branch. For convenience, I name the branch as "feature-[A SHORT DESCRIPTION OF FEATURE]". I continue to work on this branch until I implement all the requirements. I send beta distributions from this branch and stay here until the QA team confirms that the feature works as expected. When I'm done with testing, I merge this branch into featureComplete, and tag the featureComplete branch with the short description of the feature. When it's time for public distribution, I get my build from this branch as everything here is tested and ready for action.
  • prod branch: This branch contains the source code that's publicly distributed. For example, when I submit my iOS app to the App Store and we release it, I merge featureComplete branch onto prod branch. I tag this branch with my app's version and put a short description of what this version contains in the tag's description.

Now, let's think about the usual scenarios:

You created your feature branch, worked on it and when you're done you merged it into featureComplete. What to do with it now?
Of course, you can delete your feature branch when you don't need it anymore but I don't prefer to do that. Since it's not a burden on git to hold these branches, I keep them there in case I need to do something (who knows what) with them. I'm guessing that git is only holding some pointers to keep those named branches, so I'm comfortable doing this.

You discovered a bug on your production code and you need to make a hot fix.

Check out your production code, do your hot fix on this branch. Use git cherry-pick to pick your hot fix commits and apply them onto featureComplete and your active feature branches that you're still working on. I keep this rule that only implementation that can be done on the prod branch is a hot fix. Otherwise, I don't work on it directly, I just populate the prod branch with merges from other branches.

You're working on a feature branch. Then due to the reasons above, you needed to switch to another branch and you want to get some of the code that you wrote on the previous feature branch.

Find the commits that you'd like to get from there and cherry-pick those on your current feature branch. 

As you can guess, for this system to work well, your commits need to be as atomic as they can be. This will help you when you want to cherry-pick because you'll be able to pick just what you need. If a commit contains two separate change sets, and you happen to want only one of them when the time comes and you want to cherry-pick, you'll be sad. So, happy branching! :)

Monday, January 12, 2015

A little bit of background

As of now, I'm a developer with 9 years of software development experience. For 8 years, I worked in a couple of different companies as a developer & a team leader. My portfolio covers a wide range of applications including desktop & web apps, military simulation software, backend software that integrates the end users with IP phone & IP TV services, and more recently, iOS apps.

A couple of years ago, I needed to find a way out of the corporate life because I no longer wanted anyone else other than myself as my boss and I was dreaming of building my own small company where I'm developing my own products. So, I made a plan. Back then, I was a backend software developer and I didn't hear anyone looking for a backend developer for an indie contract job. That's why I decided to get my hands on the mobile client software industry because there was a big demand in the market for Android and iOS developers. Having an Android or iOS development skill in my toolbox, I could easily find a contract job and that would help me get out of the professional life I wasn't happy with. So, with no mobile development experience, I applied to a company and they offered me a job that pays less than what I was earning at my previous job. I accepted this offer because I know that a new platform / new language is best learned when you absolutely need to learn it. Besides, they were going to pay me for learning a new thing I was going to learn anyways, so why not? :) I started as an iOS developer here with no background of iOS development. I learned iOS mainly by watching those Stanford University lectures by famous Paul Hegarty, and tight deadlines at work and nonstop customer pressure brought me up to speed.

After a year our iOS development team got bigger and I became the team leader. I enjoyed working with all my teammates and we learnt a lot from helping each other. Between 2011 and 2013, I had my hands on many iOS applications for banks, pharmaceutical companies, retail and entertainment sectors in Turkey, together with eBay's retail projects in US, Brasil and Russia.

At the end of 2013, I was finally ready to spread my wings and fly away! I had collected enough capital that would let me survive for a year. Together with a couple of friends of mine, we had a startup idea on our minds and with all these arrangements combined, we were ready to begin our startup journey.

A few months later, my friends and I met two other like-minded co-founders who have also been implementing a similar startup idea to ours for 2 years. We thought it would be best if we could join our forces and we became a team of 6 to renovate and improve Giysicini, a social fashion platform. Around the same times, a friend of mine and I co-founded another startup named Cheers. We were spending half of our time at Giysicini and the other half at Cheers. With Cheers, I worked on an iOS contract job and we developed our own push notification infrastructure product. We earned a good amount of money that kept all things going - which was the whole reason behind these two activities. At the end of 2014, I decided to let go of Cheers because I just simply wasn't happy. I'm sure now and then I will want to write about those things that made me feel unhappy at my first startup in order to share my experiences here.

So, my new venture started as of this week and I'm the founder of my own company, named Tardis. As you can guess, I'm a huge huge fan of Doctor Who, thus the name Tardis. For me, "venture" both represents the entrepreneurial ventures of my startup life and an attribution to all those risky and daring journeys of Tardis, so I'm so happy with the name of my tiny little company!

I intend to keep this blog to share bits and pieces of all my learning experiences along the way, both technical and non technical. Hope you enjoy!