Fujitsu Liberouch

in

My first interaction with a “keyboard” is the traditional type writer by Olympia. I still remember the click sound, and also the weight of each key. Later on, I get my first computer, which is the Apple II and I realize the keyboard is so much lighter and the click sound is just lovely. Flying forward and I came across all sort of keyboards for both PC and Mac, from the “no-frills” to different kinds of Apple keyboard - those for the Bondi Blue iMac, or those for the PowerBook.

I love the touch of Apple Keyboard and hope to find a similar keyboard for my Visor

I believe my journey into keyboard starts here. I love the PowerBook keyboard and when I start using the Visor, I tried to look for one that resemble the touch. And it was the Newton keyboard that satisfied my desire; very portable, key size big enough to type continuously and I can fool myself typing on the Apple Keyboard. Since then, I came across the keyboard by Logitech, the Apple bluetooth keyboard and so on. I know nothing about mechanical keyboard and my focus is wireless connectivity.

HHKB is the geeky keyboard with no print on caps and feature the UNIX keyboard layout

This is when I first heard about Happy Hacking Keyboard, which is more than 10 years ago. I was intrigued by the fact that, a keyboard that is geeky with no print on caps and feature the UNIX/Solaris keyboard layout. But it never caught on as no way I could afford the expensive keyboard.

One day in 2013, I finally get to know the world of mechanical keyboard. And I got my first - the HHKB Pro (which worth a separate entry on it’s own)! Since then, I extended my collection and today, I get an interesting keyboard which isn’t truly mechanical but the working mechanism is similar to another legendary keyboard, the IBM Model M which are both membrane type keyboard. So here it is, the Fujitsu Libertouch!

My first impression is how sturdy and heavy the keyboard is. With a weight of over 1Kg, it definitely won’t slide on the table while you type. The pressure of the key is controlled by the plastic dome. Fujitsu is very thoughtful in providing dome of different “resistance” so that we can arrange our own zoning. Keys are laser edged, and typical 101 keyboard layout which means I need to adjust since I am more used to the HHKB layout (i.e. CTRL and CAPS position are swapped).

I like the little pool on the top right hand corner which I could put some pins or even a small post-it. The touch of typing is in between the cherry red and capacitive switch. If I have to choose, I would say it resemble more to capacitive than Cherry. And more towards the Realforce than HHKB. It’s quiet, but not as quiet as the silenced HHKB Pro 2 type s or Realforce silent. Another different is, it can’t be programmed. Since I am a Mac user and I surely would want to switch the key of the Windows key with the Alt key. And like I have mentioned before, I am feeling more comfortable in having the key next to my left little finger as CTRL then CAPS. But again, I can’t do anything with it. The keyboard is quite high without pulling out the feet already and I hope to use the palm rest from Filco but sadly, it doesn’t fit.

It’s a nice keyboard but it probably will not be my primary for the reason of key layout (alt/windows key, CTRL and CAP. I know I can change the keyboard mapping in OS but not my preference) as well as size (prefer 10keyless).

Technology - solution to a problem

in

During a lunch, our boss is showing off his version of NFC iPhone - sticking an octopus card at the back of the iPhone. He elaborates that, from the dictionary, technology means a solution to a problem.

I am a bit skeptical, not because of the definition but his interpretation.

Using technology to solve a problem is always right, but one of the semantic is missing in the statement - quality of the solution. For example, cars in the early days are powered by steam engine, it sucessfully substituted moving cars by animals but they are slow and break down easily. 

If the easiest approach is always taken, we are sacrificing quality for speed.

Let me share with you a story. We have a system that would send goods picking message to the warehouse system. Overtime, there are messages gone missing which results in late order delivery. The current approach to transmit the message is to replicate the data via some intermediate data table. There are times that data failed to replicate, which is due to network or database level issues. A developer is working on a change, suggesting to write directly to the warehouse system instead of relying on the intermediate tables.

Seems to be a logical move as writing data directly to the target system get around the issues of replication. But I have to pull him back, and reminded him on the coupling now increases. Any schema change on the warehouse system would break our application, and not to mention our system's availabilty is now depending on the warehouse system as well. 

Like a clown juggling balls, architect juggle the decision around technical attributes. 

As the architect is the person responsible to device a solution to a problem, one of the challenge is finding the optimal sacrifice, or finding the right solution. It is our job to explain to the user, on all the concerns taken. We are responsible for the end product, not only delivering it but ensure it works all the time efficiently. And we are not only dealing with the delivering team, but also with the business team, remind and persuade them that things are not always that simple.

 

Doing it properly

in ,

When I begin working on Project Rhea, the first thing I remind myself is to do it properly - proper infrastructure, using the tools I pick in the proper way, defining a proper development procedure and only release application with proper testing.

With the project now gone through a couple of sprint, I am seeing "proper" a little differently.

I start off the project with the installation and configuration of Jenkins, which soon I told myself, "Wait a minute! Provisioning and configuration should be automated!" So I steered away from Jenkins to Puppet. And I realize it is a beast quite hard to tame (I will leave it on why I say so in another article) but anyway, I have finally get some configuration written. From there, I realize another thing - I should have the configuration versioned and now I need a GIT server. So there you go, I dropped everything and start working on GIT installation.

Do you still remember what is my original intent? Jenkins installation. But instead of working on Jenkins, I am now dealing with 3 different other things!

All the tasks I mentioned are proper things that should be done but none would resolve my immediate needs - I want to setup a CI server and get a feeling on what it is, how it should blend into our development process.

What's more, the split hinder you from getting the feedback you need and the struggle give you stress (as nothing is achieved), instead of satisfaction.

So here is my first challenge - balancing immediate needs, against taking the time to pave the foundation.

Now with the barrier of adopting Puppet been overcome, the amount of configuration defined start to grow, too. Also, I begin to define the Jenkins pipelines and I am struggling if I should use a single pipeline for all instances or one pipeline for each.

And here comes another challenge on "proper" - am I doing the changes properly?

These conflict lies in the struggle of doing both things on the same environment. And the way I resolved this is, I pulled up a throw away environment so that I could fast track in getting the information I need, while at the same time, I can refine my plan and decide the tasks that needs to be taken. With free starter plan from AWS or Azure, it costs nothing to do experiment. In later stage of my project, I extent this throw away experimental approach to other things as well. For instance, instead of defining the puppet configuration for packages or changes right away, I will first experiment on the sandbox and only until I feel "this is it!", I will then put the changes back into Puppet as configuration.

One day, I came across an article written by an engineer in Google (https://conf-slac.stanford.edu/xldb-2013/sites/conf-slac.stanford.edu.xldb-2013/files/JDean.pdf), talking about the infrastructure development history in Google. It inspired me with my new principle. 

Nothing is final, we can always revisit and refactor as needed. If the Puppet conf growth t oa point of losing control, we refactor.If we rolled out a pipeline that didn't work for the developer, we go back and tune. The flip side of this appraoch is, we got a more concrete statement on what is wrong and what issue to tackle.

Lastly, I want to share with you on how I am seeing "proper" now. Proper, to me, is a state of mind. What is proper depends on what is needed now. Also, don't be afraid of change. Re-define when you feel you are diverting from your original intent.

Tools

in , ,

Have been using vSphere extensively over the years and we finally started using vCenter to manage all the hosts. I am happy but not excited, not because it is bad but I just don't feel the craftsmanship.

I use a lot of tools at work and I picked what to use all with a reason. Lately, I spend a lot of time in configuration management and Puppet is what I am using. A similar offering by VMWare is the Orchestrator.

With both tools on hand, why would I prefer learning Puppet than Orchestrator? Probably comes down to,

Openness
I am not confining myself to a particular stack of technology, I can use Puppet to manage instance virtualizing on whatever platform.

User base
I can pick up a lot of resources on this tool since this is so common.

Best of breed
Puppet focus on what it do best and rely on (or people find a way to) other tools to fulfill the other needs. For instance, we are using GIT to manage all the .pp files versioning, access control by PKI, etc. While for Orchestrator, it is taking care all by itself. If vSphere is the only tools we use, this will not be a problem but we are not.

By the same token, this explain why I would use New Relic, Zabbix, Jenkins and Nexus instead of vFabric.


Stepping forward to 120

in

I love photography.

I love seeing around and always want to capture the special moment. The falling leaves, the sparkling eyes of the kids, their un-reserved smile.

I am stunned when I see the the photos taken by Hideaki Hamada - the atmosphere, the framing, the facial expression of the boys, the color, the tone. And I found the framing is interesting and turns out they are taken by a "medium format camera".

So I started looking around on what it meant, how does it differ from the 135. From there, I learnt about the format, the camera and seeded the desire to step forward.

I looked at all the format and decided 6x6 or 6x7 is what I want. The square format always hold a place (that's why I love using Hipstmatic) and I think I am quite ready to compose in this format. And next comes down to gears. Looked through Mamiya, Pentax and Fuji. Unsurprisingly, I go for Fuji, for it to be the lightest among all and the EBC coated prime lens is always my favorite. But I am not too certain about the focal length (28mm as in 135) as it's not the focal length I am most comfortable in.

After weeks of struggle and analysis, rolls of films I have taken. I know that I WANT to take pictures and this gear can bring me the sharpness in focus and clarity in imaging that I always strive for.

So after two trip to Filme, I have brought the Fuji 670W home, together with 3 rolls of films. Film, like fountain pen, give me a sense of un-repeatable happening. Unlike using digital camera, which you can just blast the shoot and pick one you feels right. For film camera, you have to be totally focused in getting the absolute right.

Now I have to get myself familiar with this, take a lot of picture and enjoy.

Think, before you ask.

in

We encounter questions more than answer and we would love to get the questions offload from our ship as soon as possible.

So we either do it ourselves, or ask others to do that for you, partially or in whole. And since we have so much to achieve and thus, a natural tendency is to ask the help from others.

The intent itself is fine but think about the last question you have asked. Is it along the line of "Something doesn't work" or "The app is so slow".

The question I am being asked most by the developer is, "Ronnie, I clicked the link bit it doesn't work". The second runner-up is, "The site is slow, why is it?"

These are very open ended question and lots of possibilities. But one thing in common is how one (or I) can start investigating it on - log reading. But people are just lazy and would rather get an answer straight from someone, instead of figuring it out themselves.

They can get the answer quick, but traded off from learning. Every single incident is a chance to learn, you pass it over to someone (or me) just meant giving up the opportunity to learn. You forgot what you've been told very easily but remember life long if you worked this out yourself. So next time, think before you ask.

Beauty of simple

in

Spent 3 nights at a machiya in Kyoto. One thing that strike me the most is they way they layout the space. It isn't spacious but still, significant amount of spaces are reserved for things like, a small zen garden, a square in the living room for displaying art piece.

In Hong Kong, those will be blocked as a cupboard or something for storage.

But this demonstrate how the two races value against beauty, or arts, into their life. For Japanese, I can see the beauty is indeed a necessity, which they will put it into practice in the meal they serve, the way they dress, all things that happened in daily life. They would given up, space for example, for embracing the arts into their life.

Now, I am practicing the idea of having less but embracing the remains, embracing the room we granted for ourselves.

Why do estimation always wrong?

in

It's been asked by every boss or project manager. Everyone got their own version but mine is always like,

- too religious towards the end date
- over estimate the efficiency
- a tendency to accept excessive risks

When a new project started, the first thing being asked (or told) is, "When could it complete?'" or "We must finish by bla bla bla.".

In the first scenario, even though the end date is not pre-defined but the project owner usually already got something in mind. Thus, the end date looks flexible but not really that flexible. Whenever the team comes back with a date later then his desire, the usual and only response is "Finding more people to do it"!

Instead of spending time to discuss on what the risk are, "solutions" are being put forward right away. The outcome? Pitfall is being skimmed through.

Another common management principal is, parallelism. Can we work in parallel? Could a task breaks further down? It could work, but only if the team is well balanced. When the project demands a particular skillset which only a single entity can fulfill, asking him to context switch and leverage the resources will not shorten the development time. Also, there's an overhead on communication, which if not managed properly, can result in tasks undone.

When we do estimation, we are always ignoring the fact that we are not as efficient as we want to be. Able to spend 70% on the project is already very efficient. Take myself as an example, I am spending 50% of my time helping to team to resolve projects issues, 20% on daily matters (like development and operation daily issues). But I am still assigning tasks to myself which leaves out to at most 30% of my available time.

Are there solutions? There is, but takes time to practice, which I am still working hard on.

Be persistent. Don't give it up or rush out for a decisoin even when we are pressed. There are not as many "life-or-death" issues. When we need to labor a baby, there's no short cut but 9 months of pregnancy.

Be realistic. If we can only afford 30% of work hours, stick with that. Don't try to fool yourself, or your project manager that the week after will be better.

I don't know about you but to me, family and health is more important than work. Save your late night and weekend, you've got a life project to fulfill which don't stand a second chance.

Short coming as feature

in

I visited Kyoto lately and during my research for my trip, I learnt about Kailado, who specialized in making container for tea leaf from copper, brass and stainless steel.

It required some skillful hand to make those perfectly shaped, air tight container but one "feature" they highlight is, the container will change in color over time.

The change in color is due to the material getting anodized, in layman term, it gets rusted.

Some will treat this as a short coming but it is indeed packaged as a feature, where each identical item will become different, with our own personality. Thinking further, it is a natural occurrence. Instead of getting rid of it, we embrace it.

But how does this translate to our technology?

System is not likely to be perfect, but the main function should be very well polished and user will find their way in using it.

Burn out

in

"Can you try getting this to work? The biz user need this for bla bla bla"

"I know it is a last minute thing but we definitely need to have this in the next day"

Sounds familiar? Each of this stands a business value for sure (assuming they are making sensible judgement) but the fulfillment for each of this means "something" is taken away from your team.

If you have some gaming experience, you should be familiar with the magical skill, or that fatal stunt attack. They are powerful but also in limited quantity.

The "something" I refer to in the earlier paragraph works in the same way. We do the stunt and penalized a bit. When we are doing it repeatedly, we burnt out. And the sad thing is, it is very difficult to get recovered.

Unlike the fantasy world, where portions in different color could help to regain the magical point. In reality, we need both time and courages to recover. We need plenty of time to rest, to rebuild the interest in the project and to plan out the to-do. We need courages since the deliverable we are going to deal with is very likely to be broken - another penalty in doing last minute stunt.

What makes it even more difficult is, both ingredients needed are usually taken away to fire fight the instability of the system.

So your best bet is to try finding some additional resource, to start off from scratch or to find a pair of new legs to do the job.

We need to be both specialist and generalist

in ,

Dynamic is one of the nature of Agile - priority varies as needed, team member can take up different kind of tasks as the project sees fit. And to achieve this, everyone should possess a wide range of skills so that they are able to cover up one another.

For instance, during the initial stage where most of the time are spent on design, env setup, etc. This demand the team to functions like an architectural and engineering team.

When the foundation is up, dev begins and the team is becoming a development factory. Coding becomes the number one thing.

When it is approaching launch date, everyone is focusing more on polishing the deliverable - intense testing, user training are the job of focus.

I agree that in each sprint, these tasks should all be covered. We need to design stuff before we can code and test but what I am trying to say is. The proportion of such work shall never be constant. It's natural to spend more time on design initially instead of towards the launch day.

And by doing so, this brings benefits to the next activities - debug and support.

In the old days, when team are focused in a single area and communicate with others through API. When things went wrong, the issue will need to pass from one team to the other. What makes it worst is, each team member will focus on a particular part of the system and not knowing the rest. Identifying the right person to ask and awaiting the reply becomes a challenge. It us not surprising when this has to be repeated for a number of times before the cause is found.

But in the agile team, if everyone is able to do go through the system and perform initial inspection. This enable a much better response time.

Also, by knowing how the system works, this enable the team to think through while they code. They can identify what is possible to happen more easily.

Sounds too good to be true. The drawback of this is the difficulty in finding the right person and the cost of hiring them. But if u have a team like that, you can move on and endeavor much flexibly.


Cultural Differences

in

Agile, scrum, are all principle to get the teams proceed in a steady pace, with great visibility. We plan on what to do in a fixed period of time and re-prioritize things as needed.

But have been running like 6 sprints and yet, we don't see the steadiness expected. Team is working long hours, feeling stressful, cannot deliver quality deliverable.

Come to think of it, I have noticed the following.

1. We keep adding things to the originally planned task lists.

2. We take dead line as DEADLINE

3. Admitting mistake is shameful

Being a Chinese, we are not good at saying 'No' and especially when the request is coming from the boss. It is not a common thing in telling the boss that something cannot be done.

And we are reluctant to change, and enduring an ever changing requirement is something not in our culture. Personally, I disagree to reject things just because we don't want to take changes. Pushing back should only because what's working on is of higher importance.

Also, asking for help is like raising excuses, we don't see it proper to postpone when a mutual consent has been established.

Lastly, admitting mistake is shameful. Cover up, denial or finding excuses is more common. But then, this results in inaccurate judgement, especially on determining task completion.

There are also some simple thing which differs between Chinese and westerner. We take lunch quite seriously, we rarely skip lunch, or do a quick one. Eating an apple as lunch is not our style.

Getting scrum or agile to work for Chinese might need to tweak a few things but the most important thing of all, is to make people understand the principle and follow it religiously.