|
Tuesday, April 22, 2003 |
|
Andrew "Bunnie" Huang's tutorial on Hardware Hacking [bOing bOing]
In one of my many other lives, I'm a hardware hacker. Most of my hacks have been on systems that run with a 1 megahertz internal clock; modern [but not pin2k] pinball machines and earlier video games. Outside of that, I stick to the purely analog or to monolithic circuits. I have long felt that hobbyist electronics has suffered a near-fatal blow at the hand of modern digital electronics. Certainly, most construction projects in Nuts & Volts (one of the very few rag subscriptions I actually keep around) involve programming of some sort or another. Certainly, the growth of reduced-cost-through-super-small-surface-mount-components-backed-by-embedded-code that has long been the trend in the electronics industry has stymied the 'recycling' efforts of many of us hardware hackers from previous decades. Reading Cory's notes from Huang's talk indicates that hobbyist electronics is not dead and that there is hope for the hacker wishing to toy-up last years most popular electronic toy that is this years dollar store loss leader....
Of course, he does mention 'ion gun' in the context of imaging the surface of a chip. I think I'll revise 'hope' to 'a glimmer of hope'..... |
|
Venting here... So, I'm in need of an ordered map. That is, a Map type object whose values can be ordered/sorted. No big deal-- there has to be an object around that implements both the Map and the List interface. SortedMap is not a solution because I need the sort order to be based on something other than the key (and I need true List like features). No problem -- there must be a class that implements both List and Map. How could there not be? It is such an obviously useful and desirable combination! Wait! There isn't such a class.... OK -- no problem-- I'll write one:
public class HashMapWithVector extends HashMap implements Vector
{
private List vectorizedValues = new Vector();
...
}
Dead End! Map defines the remove() method as:
public Object remove(Object key) List defines the remove() method as:
public boolean remove(Object o) Because Java does not use the return type to distinguish between method signatures, there is no way to create a class that implements both the List and Map interfaces. Instead, I'm stuck with choosing to conform to one of the interfaces-- I chose Map-- and exposing the functionality of the other interface either by exposing the encapsulated Vector or by implementing as much of List as I can and jumping through various random (typically typecasting) hoops all over the place. If I expose the encapsulated Vector such that I can pass the instance of HashMapWithVector off to various API that requires a List conformant object, I run the risk of having one of those APIs modify the contents of the vector and having my HashMapWithVector instance get out of sync.
The truly stupid part of all of this is that there is zero reason for the remove() methods to return different types. The List version could easily return the object that was removed; non-null means TRUE, null means FALSE. I suppose I could choose to implement three classes; AsMuchOfMapAndListAsCanBeStuckInOneClass, HashMapWithVector and VectorWithHashMap with the latter two implementing Map and List, respectively. AsMuchOfMapAndListAsCanBeStuckInOneClass could contain an instance of both a Map and a List. HashMapWithVector and VectorWithHashMap could be interchanged by merely creating a new instance of the one from the encapsulated List and Map of the other. How nauseatingly stupid. If this problem hadn't been present in the JDK for quite a long time across a number of releases, it could be passed off as simple oversight....
I'm hoping that I just missed something painfully obvious and someone will send me a 'Jeez, bill, you dumbass! Just do this....'. |
|
Now with two well designed frameworks that abstract persistence AND work with Zope (Ape 0.6, Modeling 0.9pre4), I can start evaluating their usefulness for migrating existing applications. ...... [Industrie Toulouse] Quite the excellent and well considered analysis of various random Python object persistent solutions. While I have an active disinterest in Zope compatibility for various reasons, any well designed persistency solution for Python should work just as well within Zope as without. On the Java front, Hibernate looks interesting. Of course, all of this is just an effort to find a persistency system that remotely comes close to the features of Enterprise Objects Framework while de-emphasizing fallout from working exclusively with a relational store.
If I can find the time/energy, I have a rant on that subject as I am frequently amaze/frustrated as to how many "experienced" or "respected" developers completely fail to grok some of the basics of object persistency. Relationships Good. Exposed SQL Bad. Transactions Good. Validation Good. Layering Good. Pushing Business Logic Into Database Generally Bad, Somtimes Good. Pushing Business Logic Into GUI Code Very Bad. Meaningful Primary Keys Bad. Primary Keys Good. Distinguishing And Enforcing One-To-Many, One-To-One, and Many-To-Many Relationships Good. Consistent Naming Scheme Good. Abbreviated Attribute Names Bad. Changing Schema Without Telling Dev Team Bad. Distinguishing Between Null And Zero Good. Unit Tests Good. Etc. |
|
It's been long overdue, but I finally sat down and configured my tcsh to work the way I wanted it... [BonkBlog] Urban actually took the time to parse through the tcsh man page and configure tcsh in a number of ways to make it more friendly/powerful.
I will definitely have to integrate his changes into mine and add a few other features. |
Last update: 1/5/04; 9:40:40 AM .
