dmaks: (Default)
Hi there,

If you would like to pair program with me using Ruby, possibly Rails:

  • I am usually available in the evenings (NZ time), except Friday and Saturday.

  • As I have more success pairing on katas, rather than on real projects, unless you can show me how to pair well on a real project, let's do a kata.

  • Kata list

If you're ok with that, drop me a line.

How to connect:

ssh -p 443
tmux attach

Macbook failure

Wednesday, 24 July 2013 07:01
dmaks: (Default)
I’ve had my Macbook Pro fail on me recently during a CPU and disk intensive work, spinning up the fan and heating up, it hang. After turning it off and on, it wouldn’t see my hard drive. I’ve booted from USB only to find it heating up and spinning fan again after some time, and also when the screen went black from inactivity it didn’t show me password prompt!

I figured, it could be SATA cable or logic board failure, leaning towards logic board, because, after all, it failed to work when I booted off USB. However, the repair shop told me it was the SATA cable failure, and after removing the cable I’m now working on the laptop just fine.

So, in such a case, it probably is feasible to bet and buy a new cable (the cheapest I found was at and not pay for diagnostics (cost me $80 NZD).
dmaks: (Default)
This is a post originally written at Jun 20 2013. Moved from tumblr here.

1. I’ve just finished a fixed price freelance job which I thought would take me 2 hours, but took 8, due to third-party components problems.
2. Also, I failed to fulfill all requirements, so I can’t even charge the full price.

It seems to me, if I split a task into smaller chunks, I may be burned less. In this case, if I did 2 milestones:

* Make website screenshots one at a time (no concurrent requests) for 50% of the price.

* Many concurrent requests for other 50% of the price.

I would still fail, because I’ve overspent time on both tasks. It would also be no good to stop doing a milestone because I’ve already spent too much time doing it because of the contract with the client.

What could be done about it? Only doing tasks that only use good old known components for a fixed price? Having a 3x-4x multiplier for tasks that have new untested components seems like a good idea. Would save me in the case of the first milestone, but not in the 2nd.

The question in this case - when do you give up? I gave up when it became clear that no existing components would work without fixing them first. And that would require a lot of time. But, giving up after spending allocated time doesn’t look good to me, maybe 1.5x of allocated time?
dmaks: (Default)
Another job I've got is about installing a PHP webapp into a new server. The client mentioned that the webapp cost him an insignificant sum of money (I would have taken twice the money for doing something like that I guess). It turned out that, neither the app create its database on the fly nor provided a script that created db/user and tables. And, certainly, no documentation. It turned out, the database consisted of many tables and I had to either deduce from the code what the tables/fields were or take the existing (thankfully!) database from the old server. But, after spending almost two hours moving it, it still didn't work.

Also, I've made another mistake on charging, which is, I thought I'd finish it in 1-2 hours, so I said it'll cost $30-60. Too bad. In such cases, there's really no way to estimate how long it'll take. I should have gone for hourly job instead of fixed price. Anyway, I'm not going to continue it unless I'm paid per hour. Either that or I'm happy to take $35 and leave it to be finished by somebody else.

It's ironic how it costs so much even to move the webapp to another server when it cost so little to develop it. But, if the original developer made a better effort to create documentation, database creation script, even installer, it would cost more in the first place, but it would cost less now (and in the consequent installations).

Code coverage

Sunday, 21 July 2013 06:24
dmaks: (Default)
Code coverage is a good metric that influences the way I write code (TDD does that as well). I've had sleeper thread and its variables coupled with the other parts of the system, and didn't think much of it, but now I'm glad I've looked at code coverage (it was 30% and I decided to improve it), the resulting code is better!

What I did - I've moved sleeper thread defined within the main class into a separate class, and all of the interaction with the thread is made via new class. Makes code cleaner. A side-effect of that is that I no longer have @sleeperMutex - a mutex for the sleeper thread, now it's SleeperNotifier.mutex.

You can use Coveralls, an online service providing a coveralls badge for your project. Though it has ongoing problems as of now.

Badges like this: Coverage Status


dmaks: (Default)
Blog about programming, Linux and Mac

October 2013

20212223 242526


RSS Atom
Page generated Friday, 20 October 2017 04:57

Expand Cut Tags

No cut tags