Thursday, October 4, 2018

Front Suspension on E-Twow Electric Scooter

Etwow scooters are sold under other brands too, including Frugal, SXT and UrbanGlide. I am not actually sure ETWOW is the original manufacturer or just another brand and scooters are manufactured by a yet another company.

I got myself a used one, and it came with several issues, one of which was a stuck front suspension. But first things first. This scooter has no air in tires, instead it relies on a spring front and rear suspension for comfort. In order to actually benefit from it you need to regulate it to your weight so that there is a sag when you mount it. The rear one is very easy, just loosen the screw tightening the spring. The front one has such a screw compressing the spring too, but the access is not easy. You need to detach the wheel and the steer pipe and then you need a special tool, a deep socket wrench size 10 if I remember correctly. Car mechanics usually have those if you can't find it in a store. See the photo below of how the scooter looks like being ready to loosen the tightening screw. Here is a link to the service manual for the scooter. You need to block the screw from the bottom with a 10 hex key, and turn from the top with the socket wrench. That socket wrench needs to be deep because there are four screw nuts on top of each other.

For my electric scooter that adjusting was not enough though. The suspension was stuck because the plastic hexagonal bed was too tight for the metal rod that was moving in it. A friendly mechanic polished the metal rod by hand using some sort of metal grinding tool (no machines involved) just to make it a bit thinner so that it would move freely inside the plastic bed.

Even with the suspension working the ride is still not as comfortable as on a full size bike with no suspension. I don't think it is the superiority of air tires over a spring suspension, but rather a function of wheel size.

Disclaimer: Before all this work, I contacted etwow for some information on how to adjust the front suspension and the person I talked to claimed the front suspension is not adjustable and that the tightening screw is holding the spring in place and loosening is not advised. I consider that bs. I worked out how to adjust it, got it adjusted to a greater comfort and hence am sharing the knowledge.

Alfa Romeo Giulietta Worn Hatch Button Badge

This post is about replacing a hatch button badge that looks worn, but the button works fine. It seems to be a common issue for the model brought on by the way they are attached; I explain below. You pry the aluminum logo off the button with a knife - start with stabbing it near the edge toward the center. The logo badge is attached to the plastic button underneath with an adhesive. It is a 3 millimeter thick layer of soft adhesive that is only present in the center of the button. The adhesive not covering the whole button is most likely the reason for the wear, as the damage happens near the edges where there is no adhesive to support button pressing.

I attached a replacement badge using silicone just because I had some and it seems to have a similar consistency to the original adhesive and would be similarly easy to detach should I ever need to. I tried to distribute the silicone on the whole button, not just the middle, to prevent deformation on pressing. Silicone seems to hold it fine, haven't lost it yet.

As to the logo badge, you needed a 75mm wide one, the first one I bought, a 74mm one, did not fit. The badge is the same for the front and back.

Thursday, January 13, 2011

pinfruit - my mnemonic web app for memorizing numbers

I have created a web app to memorize numbers. It implements the mnemonic major system. The system works on the principle that it is easier to remember words/sentences/stories than numbers. The web app facilitates finding sequences of words that encode a number in the mentioned system. I called the app pinfruit.

My first take on implementing the system was incorrect. I simply associated digits to letters. According to wikipedia the mnemonic major system assigns digits to sounds, rather then the letters of the alphabet. And rightly so, I immediately noticed that it is easier to work with sound associations.

My mistake originated in that I first learned the technique in Poland, and in Polish it does not matter if you assign digits to letters or sounds because both correspond. Unfortunately, in English this is not the case, the major difficulty in learning the language.

I have used pinfruit to memorize mainly pins and phone numbers, but also bank site's user identifiers, which often come as numbers.

The trick is to create a memorable (vivid or absurd) sentence/story for a number. My old phone number: 07514590312, can be encoded with husky leader leaps midway Hanoi, school weather helps Madonna or sickly water leaps hometown. I refer you to the wikipedia article for the detailed description of the system.

Sunday, August 15, 2010

From layers to hexagonal architecture

The traditional layered architecture consists of data, domain and presentation layers.

Separating the presentation layer from the domain layer is rather easy. The presentation layer objects query the domain for data to display on the screen. The persistence layer is another story. The fact that it appears below the domain layer prohibits any of the classes in it knowing about the domain entities.

But consider a Fetcher class for example, a class that has responsibility for querying some domain object from the database. It has the domain type in the signature and thus has to be defined in or above the domain layer. This is leaking of the data access object out of the persistence layer.

This problem has been recognized and here we have an architecture which works around it by separating out the domain objects package. But the result is not as clear and compelling as the layered architecture.

The civilisation progressed and an architecture with nothing below the domain model has been discovered. One can see this in the ddd sample.

The persistence concern is implemented as part of the infrastructure layer. Infrastructure is that vertical layer that depends on the three other layers. Domain knows nothing about the infrastructure.

Another example is the Hexagonal Architecture.

The domain sits in the core of the application, with the persistence aspect implemented by an adapter. The adapter layer corresponds to the infrastructure and the interfaces layer combined from the ddd sample architecture diagram. The important part is that the domain does not depend on anything else.

Such layering is achieved by defining service interfaces in the domain layer for persistence purposes. These abstract interfaces are implemented by the adapters in the outer layer of the application and injected into the objects that need them.

As a result nothing in the domain layer needs to import anything from the hibernate package, or whatever persistence technology is being used. The domain layer has a custom made, abstract interface to persistence service, in its own terms. The domain code can be expressed without the details of the persistence technology being used.

Saturday, March 27, 2010

GOOS Book

Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce is a book I was long waiting for. GOOS demonstrates the techniques and highlights the patterns as they show up in an application grown through the book. An albeit small but a real world project is being developed from scratch in a way were tests play as important a role as object-oriented design.

It is an excellent opportunity to see how two skilled developers are growing application. The authors work in TDD in a style characterised by extensive mocking to avoid breaking encapsulation. In design they use fine grain classes. All together the style demonstrated in the book is very consistent.

Sunday, February 7, 2010

IronPython Dictionaries Memory Cost

Maintaining a mapping as a dictionary can be quite expensive in terms of memory, more than one would expect. A couple of days ago I have checked with windbg how much a single entry in a dictionary mapping pairs to ints costs. The code I measured is:

d = {(1, 2): 3}

I have executed it in IronPython 2.6.

The graph below depicts what I saw on the heap. Each box represents a single word in memory. In a 32 bit system, a word is 4 bytes.

Every object in .NET runtime has an overhead of two words. These are the pointer to its class and some house-keeping data, which I don't know much about. Allegedly some part of it is used for object locking.

The graph shows objects below buckets array, these are the only that count. A dictionary is a hashtable which is implemented with an array of buckets. Each item in the dictionary is kept in a bucket. The size of the Bucket object determines the size of an entry in the dictionary.

There are 23 boxes in the Bucket's subtree, which means its size is 23 * 4 = 92 bytes. Quite a lot. A million numbers in that dictionary would take almost 100 megabytes!

The main reason it comes out as that many is the generality of the dictionary. The fact that it can store objects of arbitrary types means that the numbers must be boxed. .NET generic collections, when specialized for ints, would store numbers in place saving a lot of space.

Tuesday, June 9, 2009

Extreme programming too extreme?

Is extreme programming as a methodology over? Has Kent Beck killed it himself? Until now he insisted that you not write a single line of code without a failing test. He was talking about his daughter who allegedly can not even imagine writing code without tests first (in his book about test driven development)!

Extreme programming is a set of good practices but the problem is the emphasis on taking them to the extreme thus ignoring the cost/benefit ratio. There is an obvious trade-off here.

It would be optimal if people wrote just the right amount of tests, not too little and not too much, to maximise the ROI. That of course is very hard to judge, but for sure the answer is not 100% coverage in all cases, as Kent kindly observes in his post.

Extreme programming is flawed as a methodology, but I want to argue that it is good for learning the craft.

People have natural inclinations for not testing, not integrating continuously but programming a feature for days not syncing with the main code base, underestimating features and than putting in long hours, etc. Extreme programming is like a correction program for these unwholesome inclinations. :)

Aristotle noted in the Nicomachean Ethics that the best way to reach the golden mean is to aim at the opposite extreme.

In the dimension of testing, for example, people will naturally tend to write too little tests, usually none. Practising extreme programming forces us to go to other extreme: from none tests to 100% coverage no matter the cost. This teaches that you can write tests you didn't previously realized, but more importantly it changes the mindset of the programmer. After practising extreme programming you will find yourself uncomfortable without the safety net of tests, and while you will not necessarily want 100% coverage you will be in a much better position to judge how much testing is really needed.

I am glad that I was a part of an extreme programming team for almost 2 years now. We might have been too extreme, but too extreme in the good direction. 4:1 ratio of tests to code that we have might be an overkill, but it is certainly better than no tests at all. I feel similarly about other practices.