It is the second time my phone requires service attention. And the problem is exactly the same as it was the first time - the screen either suddenly goes dim and all colors become dark or it fails to light up at all when the phone is waking up from the standby mode. Often prior to unexpectedly dimming the screen the phone starts reacting on navigation commands in a sluggish manner and usually smooth transition effects when switching panels now become staggering.
It was just this summer when this has been fixed by replacing the TFT matrix. I can hardly imagine how cheap these TFTs should be to exhibit faulty behavior that frequently. Seems like the MTBF is approximately 6 months.
Looking around for a better options I can hardly think of any good alternative amongst the plenty of all these smart-phones, communicators, etc. They just don't look reliable. Indeed, with the current manufacturing rates we will very soon be buried under a large pile of such cheap sh*t. What a nice prospect!
These little things cannot even replace firewood if it gets much colder one day. A Darwin award is awaiting for you, people! Keep going.
"I'm just sitting here watching the wheels go round and round, I really love to watch them roll..." John Lennon
Thursday, January 28, 2010
My list of features missing in Java
It is a very common question on interviews about what features you consider missing and would like to add to Java. Here is my list:
- C#-style properties accessible as such via reflection;
- C#-style yield keyword;
- C#-style as keyword;
- Get rid of java.util.Date hell - will require changes in java.sql as well;
- Function objects, specifically for bulk processing on collections; implies C#-style delegates;
- modularity, e.g. OSGi-like bundling - no jar-hell;
- Annotation-based configuration for JavaBeans, again, like it is done in .NET System.ComponentModel; extensive support in Swing;
- Something similar to org.springframework.util.Assert class for common runtime checks;
- Human-oriented Generics;
- Byte-code emitter API;
- Unified interfaces and compiler support for events like in .NET, free of known problems;
- One more feature would be nice to have - a user-defined context reference in java.lang.Class object. This would let keep all class-related extensions, e.g. persisters, serializers, validators, type descriptors, etc, acessible by simple navigation as opposed to keeping multiple mappings.
- Extremely useful feature - C#-style verbatim string literals (@"...") = multiline strings in Scala ("""...""");
Thursday, January 21, 2010
IBM eXtreme Scale vs ORMs
Ah, that's a solution I have also been thinking over for quite long time. Distributed object caching - that's the next generation platform for most applications. I am sure this is one of the most interesting areas to work in. Shall I seek for opportunities with IBM, maybe? :)
Thursday, January 14, 2010
Thoughts on validation
Would I miss anything if I guess that a validation rule applied to a single entity can be either of the two:
- An extention to a standard general-purpose type like int, double, String, etc that constrains the domain of possible values to the actual business domain. When I declare a String property as not null and having at most 16 characters, I actually give a hint to the framework to force the corresponding restriction on assigned values. Alternatively I could probably declare a new type like NonNullString16 and use it instead. Possibly a good example is the price of some asset that should never be less than zero. This requirement can be captured by NonNegativeDecimal type or even more specialized AssetPrice type. However, building a custom type for every particular situation seems rather irrational and hardly doable in most cases dut to a number of technical problems.
- A complex check on several properties correlated by some law. Examples:
for an employee the graduation date cannot precede the date of birth, for a market quote bid price cannot be higher than offer price, the number of idle resources cannot exceed the overall pool size, etc.
From Java constructors to domain-driven design concepts
Interestingly, a constructor in Java can be thought of as a callback method which is to be invoked upon instance allocation.
Subscribe to:
Posts (Atom)