Piece of code

Cyberdeck part 2: The screen

Wed, 01 Mar 2023 06:00:00 +0000

Check out the other posts about the build:

Part 1: the beginning
Part 2: the screen

or the new Cyberdeck-page to make following easier.

Continuing my cyberdeck build, I decided to mount the screen first as first part. Mainly because it’s the largest part after the case and I’m afraid to break it before attaching it.

At first, I modeled brackets to top and bottom.

They seemed to work well enough in first attempt.

However, at this point I realized that I will need some side brackets to prevent screen moving sideways.

I designed and printed brackets, but I made a mistake. I forgot that my design is not 100% accurate compared to the actual build. The rails I glued on the lid (and the bottom) are not in exact places where I designed them. Luckily, the left bracket was actually a perfect fit for the right side, so I only needed to adjust one bracket.

The screen’s driver board had a control board which I wanted to use. A mount for it was relatively easy and quick to design and print.

And this is how I mounted the driver board.

Speakers

While testing the screen that it is working and control board is easy to access, I realized something. I’m missing sound! So a quick check to stores nearby and managed to find small stereo speakers for a bit less than 6 euros.

Speakers’ own cases were too big for my use so I had to dissassemble them

Speakers without their case.

To attach them, mounts were needed. It took me couple of tries and test prints, but this is what I was happy with:

And then it was time to mount the speaker

As you can see from the image above, there is not too much of space, but do we really need that? I’d say no!

And here is the final result of mounted speakers and control board:

Cyberdeck part 1

Mon, 11 Oct 2021 06:00:00 +0000

Edit 2023-03-DD: Added build log

Cyberdeck build log

Part 1: the beginning
Part 2: the screen

[Edit ends.]

It’s been a while since the last post, but I though I’ll start to share some kind of build log from one of my current project: Cyberdeck.

Ever since I saw that my friend Heikki showed me his cyberdeck in the late summer of 2020, I immediately wanted to build one too. Not that I had any real world use for it, but it sounded really nice project where I can learn 3D design.

What is cyberdeck?

Cyberdecks are basically portable, chunky computers that takes inspiration from cyberpunk. Check these examples from Zack Freeman and Jay Doscher

Plan

The plan is to have a mobile station for electronics work. Therefore I went with the following component list:

Raspberry Pi 4 (4GB)
Breadboard
GPIO extender
12,5” 1080p screen
SSD for storage
Mechanical keyboard
Wireless mouse

Few parts of the project

Parts

This table will contain list of used materials/parts as those are taken in use in the project. It will be updated during the project.

Part	Amount	For what
PLA	-	3D printer parts needs to be printed
Case, 34x29x15cm	1pc	To hold all the tech and parts
Heat insert M3 6mm long	~48pcs	For bottom rails’ holes and speaker mounts
Heat insert M3 3mm long	~40pcs	For lid rails’ holes
Screw M3 6mm long	~31pcs	For attaching components in part 2
Nut M3	~3pcs	For attaching control board to it’s mount
12.5” FHD IPS	1pc	Screen that was meant for Thinkpad X240 / X250/X260/X270
Driver board kit	1pc	For controlling the screen and getting HDMI out
2.0 speakers	1pc	The cheapest speakers I found from the store

Note: The amounts for heat inserts, nuts and screws are estimates at it’s best, can’t remember all used ones. I might do a proper counting once the whole project is more or less done.

Case

I went with Clas Ohlson’s 34x29x15cm case. At first I was going to make the project to a smaller case that I had a spare one, but after calculations it proved to be too small for 12,5” Thinkpad screen. Earlier plans included 10” non-FullHD screen.

Design

The first step was to create a close copy of the case in Fusion360. I made only a quick mockup of the case, just to help with visualizing the project and plans.

The first problem was how to attach all the interior tech inside the case. I wanted something modular so I can later add, change or remove some parts. I came up with an idea of adding rails/bars in the lid and bottom of the case. Rails have holes for heat inserts, so I can attach my modules with screws.

Here is a pic of the rails and bars before gluing Vertical bars between the rails are only to help align horizontal rails straight when gluing them.

I glued the rails in one take with instant glue. I wasn’t happy with the result, since using instant glue, you have to be quite fast to get everything in place before glue dries. I decided to change tactics with bottom case’s rails.

By using the tape, I didn’t have such a hurry to get all rails glued and then placing them exactly where they should go.

After glue was dryed long enough, I removed the vertical bars from the lid. And in the end, both ways (all in one go and one rail at the time) worked good enough- That one black thing in the second bar from right is a pice of a glove that I manage to glue in to the rail..

Now starts the hard part: I need to start designing and thinking how I place all the parts in there.

Shoutout to another Heikki for proofreading the post and giving some tips!

Assume positive intention

Sun, 02 Dec 2018 06:00:00 +0000

In the past few years I’ve started to work mostly remotely. It’s been great journey so far and I’ve learned a lot. Mostly about myself. I’m going to share my learnings as separate posts every now and then. This first post is about assuming positive intentions.

Assume positive intention

When you work remote, your communication is mostly text based, chat, mail or issue board. Problem with text is that it does not have expressions. So it’s quite easy to misunderstand someone, especially when compared to talking with someone face-to-face. More often I feel that if I don’t put smiley or emoji on my messages, I’ll be misunderstood. And on some cases when I read my own messages, they “sound” sarcastic with emojis in my mind. And I hate that. I like smileys and emojis, they are great for expressing feelings, but when you feel that you need to put them on most messages, there might be bigger issues.

Of course there’s more variables in this. For example, if you’ve met the people you’re talking with before, you probably understand their intention better. Let’s have an example: you’re new in the company and doing a code review. Then you spot something that you don’t understand. You might comment something like ”Why you did it like this?” without thinking it further. In your mind, you mean to ”say” that in neutral, a bit confused tone. After reading it, you think that’s reasonable question so you leave it there.

Then think about that you’ve written a piece of code that you’re really, really proud of. It’s perhaps the best code you ever wrote. Then you submit a pull request. After few hours someone asks the same question ”Why you did it like this?”. How do you read it? I bet that in most cases reader will go in to defensive mode. I know I took most comments in my first pull requests like that. And it’s okay to feel like that. But before you answer and defend your solution, take a step back and think:

You both work on same project and probably want it to succeed
It’s really easy to do stupid errors when you work on some problem for a long time ( I do this all the time)
Perhaps you’ve actually made complex code that is hard to read, it can be (and in most cases it is) you, that come back to own code after a period and have to spend time to understand it

When you work at the office and you get the comments like that, it’s easy to just go to have chat with the reviewer and ask what did they mean and get it solved. But on remotely, you cannot do that. It took me a while to not get the comments as personal attack and to try to understand the feedback of the comments.

So even if it is hard to think it as a positive comment.

Sometimes it's ok to take shortcuts

Fri, 27 Apr 2018 06:00:00 +0000

I’m kind of a developer who likes to do futureproof code and sometimes question decisions that impact on future requirements. Fore example, if there’s a service where a user has a profile, why won’t we separate those into two models so in future if/when we want to have multiple profiles per user, we just need to change “has_one” relation to “has_many”. It also means proper test coverage and code split in meaningful classes. In short: no shortcuts.

However, there are times when shortcuts are fine and are required. One of those cases is when your doing POCs (proof of concepts). I encountered this recently and would like to share some of my findings.

Story time

Project X was an app that’s integrated to one external service A. Up to this date, that one service had been enough for the app as a source of the data. So some architectural decisions had been made of that. Now, with this POC, I had to jump into that project and integrate a second service B (which I had integrated in another project already, so I knew how to do it).

We held a meeting with a few key individuals from the project X team and in the end we came up with a good plan. Our goal was to get a list of items from the service and show them in the mobile app. So let’s start.

The external service is using oauth2 and has expiring tokens. Existing system did not support that kind of behaviour, so changes needed to be made. New API endpoint(s) for the mobile client -> changes needed. API tokens needs to be stored somewhere -> changes needed. New items will need to be updated at some point -> changes needed. So at least these three changes will need to be made:

New endpoints
Store the tokens somewhere
Add support to refresh data from this source, as current architecture does not support it

Last two items are quite big ones (in the terms of coding) as those possibilities with the existing architecture have not been though in the first place. Next step is to think about some estimations and tasks that are required within the POC. The goal of our POC was: Show items in the mobile app.

Okay, we definetely need the endpoints for supporting oauth2 flow. At this point, it’s easy to create some hardcoded route, but if we use parameter to define the service to be used, we can take it in as a value and thus build the system to get settings related to that service in the background -> new services can be connected pretty much by just adding new settings. It will make future changes much smaller.

Then we need to store the tokens when requesting the callback handler. We pause and realize that to meet the POC’s requirements, we don’t need to actually store the tokens. Just fetch the tokens by the authorization code and get the items directly in the callback handler. Win!

Now that we have the data, we need to convert it to fit into the existing item’s structure. This means there will be no changes in existing architecture because of that. Can’t be counted as a win as it’s what one should do and would have been done anyway.

Then the data refresh. Why do we need that? Well, to meet the POC’s requirements we don’t. So lets forget that. Another big win!

In the end almost all of these changes were done by additions, just some minor changes was need in the existing architecture.

During the final moments of the POC we received this comment, “But I can’t take that code to the production!”

Yep, you can’t. But that wasn’t the intention at the beginning. Idea was to have a POC. It wasn’t meant to be shipped to production right after. For me POC’s are (and in generally they should be) the quickest and easiest way to test thing X. Take all the shortcuts you can and focus only on the requirements when planning. Also the scope and requirements for POC should be quite simple. If you want some data from external service, it’s probably enough to get just smallest subset of it, not all that you would use in the production code.

Shout out to Chris Moore for proofreading and helping with the post

TDD as a design tool

Sun, 01 Oct 2017 10:00:00 +0000

I will use Ruby in this example, and assume that the feature will be built inside rails. Also, this concentrates more on the process and leaves the actual implementation out

One of the reasons why I keep using TDD is that it helps my thinking process when I write code. It makes me think the feature before implenting it making the implementation part really straightforward.

Feature spec

Let’s say I need to create a feature where user can send a message to other user. I’d start with following feature-spec

feature "User can send a message" do
  scenario "User logs in and sends a message to another user" do
    user = FactoryGirl.create :user
    receiver = FactoryGirl.create :user

    sign_user_in user, "password"

    click_link "Messages"
    click_link "Send a new message"

    fill_in "To", with: receiver.name
    fill_in "Message", with: "Hello world!"
    click_button "Send"

    expect(page).to have_text("Message was sent successfully")

    expect(receiver.messages.map(&:receiver)).to eq([receiver.name])
  end
end

This is the first draft of the flow I’d like that user has to go through for sending a message. Most probably it will need changes in the future, but the main point (for me) is try to make sending message as simple as possible. Also note that we’re testing only that user gets A) notification about successful sending and B) there was one message that were sent to correct receiver.

At this point I start to run specs and write production code until I need to create a new class (e.g. controller).

Controller

Next spec file will be for MessagesController (as we don’t have controller named like that yet).

RSpec.describe MessagesController, type: :controller do
  describe "#create" do
    context "receiver exists" do
      it "message is sent with username"
      it "message is sent with userid"
      it "message is sent with email"
    end
    context "receiver does not exist" do
      it "message is not sent"
    end
  end
end

So before I write any line of tests, I try to write down the “features” of the class I’m testing. As this is a new feature and we’re missing the Message object, we’ll need to hop on to write spec file for that

Note: In some cases, there’s no point for creating specs for controller (for example if action is just listing items, that can be tested in feature spec just fine). But in this example, we’re not sure how we’re going to implement the feature, so I’d follow the style and create the spec file (we can always refactor specs and remove them if they become obsolete).

Model

On the model, I follow same process as with controller (and other classes), drafting out what the class should do.

RSpec.describe Message, type: :model do
  describe "#send_message" do
    context "receiver exists" do
      it "message is sent with username"
      it "message is sent with userid"
      it "message is sent with email"
    end
    context "receiver does not exist" do
      it "message is not sent"
    end
  end
end

As we can see, it’s pretty similar with our controller spec file. So after we’ve implemented Message, we can refactor the controller.

Refactor controller spec

So we have now tests to test that message can be sent with username, userid and email, we don’t need to test the same things in controller. Instead, we should just test that message is either sent or not.

RSpec.describe MessagesController, type: :controller do
  describe "#create" do
    context "receiver exist" do
      it "message is sent"
    end
    context "receiver does not exist" do
      it "message is not sent"
    end
  end
end

Now we’re testing two paths, happy and unhappy. And to be honest, we probably should get rid off the whole controller spec by adding unhappy-feature spec. But it’s ultimately up to you and how you like to test things.

As feature specs are “expensive”, so we shouldn’t test everything there. But testing one happy and one unhappy path from end to end may serve the purpose.

Conclusion

This is how I design my code with TDD. I’ve found it really helpful to keep focus on the thing I’m working on. I either think and design the functionality or I follow my decisions and write the code “without-thinking”.

Moving the blog to GitLab and adding HTTPS-support

Wed, 27 Sep 2017 10:00:00 +0000

I decided to move my blog from GitHub to GitLab. This also makes it possible to add support for HTTPS! This also changes the domain from .net to .blog.

So if you’re subscriber (Thank you about that btw!), please updated the address to get future updates: https://www.pieceofcode.blog/feed.xml.

Use android-sdk from Homebrew with Android Studio

Sat, 23 Sep 2017 10:00:00 +0000

I recently got a great idea for a mobile app. As I’ve used react and java in the past, but not objective-c and swift, I saw an opportunity to try React Native.

On the Getting Started-guide there’re instructions for installing and configuring Android Studio. While this is pretty easy to do, I got a problem. I currently have an android phone (OnePlus 3) and I’ve already installed android-sdk through Homebrew. The “problem” is that I don’t want to download all the tools etc. more than once. And if there’re updates, I’d like that I need to do the update only once.

Set SDK path

The solution is really simple, all you need to do, is to set the path in the Android Studio to point to the path where brew installed android-sdk (/usr/local/share/android-sdk on my machine).

Open preferences and select Appearance & Behavior -> System Settings -> Android SDK
Edit SDK path
Choose location
Copy paste the path
Click OK, Next, Next, wait for possible installations and then finally Finish and you’re set!

Install packages from CLI

You can of course use Android Studio to install all the packages, but in case you want to do it from CLI (e.g. in setup script or something), you can use sdkmanager. Here’s the command for installing packages stated in the Getting Started-guide:

sdkmanager "add-ons;addon-google_apis-google-23" "platforms;android-23" "system-images;android-23;google_apis;x86_64" "system-images;android-23;default;x86_64" "platforms;android-23" "sources;android-23"

If you get following error (as I did, not sure why, perhaps the docs are a bit outdated or something).

* What went wrong:
A problem occurred configuring project ':app'.
> The SDK Build Tools revision (23.0.1) is too low for project ':app'. Minimum required is 25.0.0

Just install needed build tools revision.

sdkmanager "build-tools;25.0.0"

Now the hardest part starts, the actual development. We’ll see if I ever get the app done, hopefully so.

Chasing productivity with iPad Pro

Tue, 25 Jul 2017 10:00:00 +0000

When it comes to productivity, I’ll try my best to get the best out of me during my work hours. I’m using Todoist for tasks, Pomodoro when coding, weekly planning to get some idea of my upcoming week and bunch of other great tools on my work horse.

Up until June this year, I had an iPad 4 mini and dual monitor setup at home and the Kisko Labs’ office (btw, you should definitely check out 360° view of our office from google maps). But for some reason or another, I got interested in the new iPad Pro with Apple Pencil. I think I came up paperless sketching for the excuse to get this toy (my “old” iPad was functioning just fine).

After browsing Reddit to see what apps-I-will-never-use I can install with pencil support, I found Duet. It’s a wonderful app which allows you to use your iPad as an additional screen with your laptop/computer. It supports both macOS and windows, but not Linux. I also found another app that does the same, but with Android support. I can’t remember the name of that app though.

Anyway, that got me thinking about my setup when working remotely not-from-home. Now that I can have dual screen setup basically everywhere I go, why not use that very same setup at home and office too? I get the productivity boost from two screens mainly because I can see my dev-browser and terminal (I’m a vim+tmux user) at the same time. That need is fulfilled with the new setup.

So I end up getting rid of the monitors at home and at the office.

After being fully on this setup for a few weeks, it has worked for the purpose. One thing I’ve noticed is that it feels much easier to take the laptop from the desk and go e.g. to couch for an hour or two. Previously there was a small, temporary negative impact on the productivity when I got the MacBook from the desk. That’s because the difference between resolutions on FullHD (1920x1080) and scaled (1680x1050) retina 13”. Also, the workspaces got rearranged as there’s one screen less. And the windows sizes. All those small things. Now I only share dev-browser to iPad, which keeps all other things in “correct” place regardless do I use the second screen or not.

Some pictures

The Setup.

My view when working.

iPad resting on top of MacBook.

At the office without iPad.

Switching to remote work

Sat, 10 Jun 2017 10:00:00 +0000

This post was originally published at Kisko Labs’ blog on last month.

In August last year I did something that I guess is usually considered as something you shouldn’t do. First, I told my employer that I might be leaving in the beginning of this year. Not long after that, I told that I might actually leave even a few months earlier. Then my plans changed again. The reason for thinking about leaving Kisko was purely personal.

I wanted to go abroad and work 100% remotely, so I could explore the world.

Telling your boss that you’re planning to quit is often something uncomfortable, that you can end up postponing to the last moment. But being honest and direct about your plans early on could benefit both you and your employer – by boosting positive change.

The discussion

Instead of just announcing that I’m leaving, I wanted to try speaking openly about my career moves. Also to see, if my employer really is the career incubator, the supporter in all situations.

It turned out it is. Speaking directly opened perhaps the most honest ‘development discussion’ I’ve ever had with an employer. I can’t say how it is in all other companies out there, but you might want to be part of one where you can have these kind of honest, constructive discussions. Our discussion – and discussions with my significant other – made me do the last change of plans, decide to continue at my current workplace.

Kisko doesn’t have a lot of experience yet with actual remote workers, even though short periods of remote work are totally normal among the team and freelancers. By sharing thoughts, we’ve been able to help each other. I can start planning to move abroad and we, as a team, can find ways to make remote working possible for us.

Towards remote work

We’ve already taken a few steps forward. As a first step, we decided to measure how many Kiskonians feel that they could work remotely for a month. We took that as a goal during our last OKR season of last year. Results weren’t that good, only 3 out of 12 felt that they could do that (we didn’t measure how many actually would want to).

As a second step, I took two personal goals for our first OKR season this year. First, to spend at least three weeks working abroad and secondly, to come up with at least three proposals on how we could/should change our way of working to give better support for remote workers.

I’ve started to work from home more, even full weeks, but usually trying to visit the office about twice a week. I’ve also noticed that others have increased their remote-day count, and we’ve had more internal meetings with people participating remotely.

Focusing on remote work and doing serious research on it has made it possible to really optimize my ways of working for better productivity.

Experiments in time management, such as using weekly reviews and planning, have given me the freedom to arrange my work schedule closer to what I want it to be without sacrificing the quality or amount of work done. For example, I’ve been able to do gym sessions at noon, something I previously didn’t do because it felt like cheating. After a break I’ve been able to get back to work with better focus.

Ease your RSpec upgrade with sed

Mon, 10 Aug 2015 20:00:00 +0000

I’ve been using linux on daily basis since 2008 and changed to OS X a couple of years ago. What I like these systems, is their powerful command line tools. Tools that helps me get my job done quicker and easier than with GUI.

Even though I’ve been using a CLI so long, it’s just so amazing how powerful tools there are, and have been for decades. This time I’d like to share a tip which may save you a lot of time in future (it saved for me)!

So, at the end of the last year and beginning of this year, I got to work with few Rails upgrades from 3.x to 4.x. This meant also that most of the gems needed to be upgraded.

One of the problems was the renamed expectations be_true/be_false (to be_truthy/be_falsey respectively) in the gem rspec-expectations on version 3.0.0.beta1. It wasn’t a big change, but depending on the size of your test code base, it may mean a lot of work to you.

But luckily, you can solve it in a few seconds with the sed

sed -i “” “s/be_true/be_truthy/g” spec/**/*_spec.rb

Breaking down the command

-i “” means in-place editing and by giving empty string for it, we do not want to use backup files. We have version control for that reason.
“s/be_true/be_truthy/g” is the command we give to sed. The s at the start tells the sed that we want to use regular expression be_true and replace that with be_truthy. In this case, our regular expression is just plain text, but you can use more advanced patterns if you like. The g at the end tells that we want replace all occurrences of our search pattern in a single file, not just the first one. You can read more about s command from the manual
spec/**/*_spec.rb this is the filter pattern for files I want the change med into. I’m using zsh so it may not work as is on bash.

Reporting bugs in Open Source

Mon, 03 Aug 2015 20:00:00 +0000

I read a blog post from the authors of the CMS I use in several sites a couple of months ago about bug reporting. The post originated from its forum, where the core developer responded to criticism about bug report/feature request rejections.

He wrote a big rant about how users should do some research before filling bug reports, so the reports will be done right. Also, this developer wrote how he is fed up with those reports which are missing some critical information he needs. Asking, those information of course consumes time, which he does not have.

I have something in mind which I want to share with you.

First of all, if you want some information, you have to ask it. Currently, in the reporting form of the system they use, contains fields for

software version
Who is it assigned for (how the hell end user would know that?)
version of the module (if it’s a bug of the module)
severity (I don’t think that user necessary knows this)
summary
description

There are no hints about what kind of information needs to be to written into the description field or any link to such documentation. So why do you blame your end users for crappy reports? How about looking in the mirror? You have to educate your users for writing better reports and guide them through the process. Just putting link to an example of “perfect report” may be enough. Or even better, show it side-by-side on the form. If you need a lot of technical details, you could (and should) use some kind of an automatic error report system.

Secondly, there was a point that the developer doesn’t have time to check all existing combinations of settings, plugins and software. All I have to say is that, don’t make such combinations possible then. Don’t allow users to set any settings, or install any plugins. Of course it has impacts to your user base, but does it matter? At least you don’t get stupid and imperfect reports! Of course, there could be thousands of combinations and you cannot test them all. That’s why you may have to deal with incomplete reports and ask for more details. It’s the trade-off you need to take (in my opinion).

I also like to point out that customer service is part of our job in these days as a developer. So if you don’t want to do that, hire someone to do it for you.

First solution is not the best one

Fri, 05 Dec 2014 12:35:00 +0000

When you have a problem, you usually have to find a solution pretty quick. It’s kind of a shame, but it’s better to do something and fail than getting nothing done. At least you know what isn’t working. It’s important to get working solution first, but usually you stop there and forget the code. Therefore you should review earlier solutions and think how to improve your codebase.

In here, I’d like to share how I started with one solution and ended up with another. Problem was: how to share membership details between Rails and WordPress. If you compare solutions 1 and 3, they differ a lot, but both solve the problem. Latter a little bit better than former (in my opinion).

Solution 1

First I thought about sharing the session between these apps. Basically, we would create unique one-time hash in Rails when user logs in. Then the hash would be saved in to secure cookie within the same domain. WordPress would use custom-made plugin to get the hash from the cookie and use a command line script to get user details from the rails app. Pretty much customization and maintaining, and sharing session like this is pretty hard to get fully functional. So I dumped this after a month.

Solution 2

Then I started to look SSO (Single Sing-On) solutions and found doorkeeper (https://github.com/doorkeeper-gem/doorkeeper). It uses OAuth and was pretty easy to install and get working. The problem was that there weren’t OAuth client plugins (other than preconfigured with Twitter/Facebook etc) for WordPress at the time. And I had no competence to create that kind of plugin. This solution didn’t allow either of the apps to have their own user registers. And I thought that users should be able to register either of the apps separately.

Solution 3

I found wp-cli at some point middle of thinking solution 2. I started to think what if both apps could have their own users and I didn’t need to customize WordPress at all. I just needed some tool to use wp-cli from Ruby. So I created gem wpcli. How about syncing the membership details? In Rails there was field for username in WordPress and whenever that value will be changed, syncing is done. This requires also some kind of settings page, where roles from each app can be mapped to each other. For example, member in Rails would be premium customer in WordPress.

This was done for spare time project, but I think that’s not relevant.

So I strongly encourage to review already made solutions and to question those constantly. It’s one of the best ways to improve software over the time and more important, it helps you to improve your skills.

Do not test your private methods

Wed, 24 Apr 2013 19:54:00 +0000

This subject came in my mind after having discussion with my colleague who creates methods with default or protected scope to ease testing.

I’m not sure why even think that you should test your private methods. At least when you’re coding with TDD, you create one test, which test that method does what it should. After you get your test pass, you create another one, and another one. As long as you feel that it’s necessary to add functionality to method.

When your method does what you want it to do, it’s time to refactor. While refactoring, you should run tests every time change is made, so that it’s easier to notice if/when you break something. Tests are something you rely during refactoring.

After refactoring, you probably have method which uses private methods which you made to make code more readable and reusable. Now, think few minutes what would happen if you change visibility of those methods from private to for example protected or default.

First, you can create tests for those methods and be happy. BUT, what about refactoring the public method you create at first place? Right, you cannot do it without touching those tests! Of course modern IDEs will rename methods or parameters almost automatically, but you lose your trust to your tests. If you change something, there is always possibility to break tests.

Let’s think it from another point of view. Assume that you are working with project which has 2-3 full time developers. Then, on one pretty day, team gets a new member. This new member gets a task to add new functionality to some old classes which has tests. This new member starts with writing tests that fails. Then s/he starts to implement the method itself. After all tests are passing, s/he wants to refactor as there is same behavior on multiple places. Now, if someone has done his job right, there is tests only for public methods and our new member can refactor and trust that s/he doesn’t break anything as long as tests are passing.

If there is protected or default methods with their own tests, s/he probably need to touch them as well. This creates a situation where new bugs might be introduced.

Think about it, your tests should test that method does what it should do. Not how it does it or how many private methods are used to gain passing test.

In the other hand what is the purpose of the private method? I’d say its purpose is to make code more readable and reusable in that specific class. Nothing else.

Fresh start

Wed, 10 Apr 2013 18:03:00 +0000

As the time is passing too quickly nowadays (at least it feels like that), I felt the old pieceofcode.net-site was more like burden than a joy to keep up to date. It was time try something new and different and so I came up with an idea to write a blog.

In this blog I will write things that touches my life at that specific time in world of programming. I have few projects coming up (with rails and wordpress) so there might come some good article ideas too. I’ll try to blog in English, but some articles might be in Finnish.

In the meantime you can find me at least from facebook, twitter and github.