milgra
about
articles
projects
blogroll
bit-101
coding horror
blameit
failblog
beszeljukmac
sghu
navigation
posts
docs
admin
|
2009-05-16 Iteration hell
|
a very common problem in java when you are iterating through some list, and an external thread or the thread itself wants to modify the underlying list
Source Code
to avoid concurrent modification exception, the most common solution is to use an iterator and add/delete the new element with it, or, if it is safe for the same thread, use synchronization to handle external threads.
my problem is that both solution needs too many cpu cycles.
for most cases, the solution below is the best :
Source Code
so if the original list is changed, we clone it before iterating through, and modification of the original array won’t affect iteration. but beware, its only good if a plus cycle doesn’t matter on the objects ( no destruction happens before removing the element ).
in those cases good old iterator has to be used.
MilGra
|
2009-05-15 Bit level compression ideas
|
What is the basic idea behind compression in computer science? To find the largest similar sequences in a byte stream, and replace them with short identifiers.
There are lots of algorythms, but somehow almost all of them are byte-based. So i started to think about a bit level algorythm.
The first idea is very simple. It’s based on a state switcher machine.
A bitstream contains pairs of bits with four possible pairs.
00 01 00 01 11 10 11 10 00
We can find an optimal sequence, where these pairs follow each other in a special order where we can step between all states in two direction.
In the above stream, the ordering looks like :
00 01 11 10
And if we say, that we step left under the code 0, and right under 1, we can describe the starting sequence like
00 -> 1 -> 01 -> 0 -> 00 -> 1 -> 01 -> 1 -> 11 -> 0 -> 10 -> 1 -> 11 -> 0 -> 10 -> 0 -> 00
So if we know the starting order, we can simply describe the starting stream on half size :
10110100
And when we are ready, we can recompress the resulting stream again the same way.
Seems good at first glance, but in real life cases its not really efficient, beacuse for perfect 50% compression we would need four directions, but we can only describe two on one bit. It works good only on special cases. I’ve run a few tests, and the compression rate was around 60-70 percent, while classic byte based routines did 30-50.
So i have to think it further.
MilGra
|
2009-04-03 When one method does matter!
|
While keeping method count minimal, we have to keep our code unambiguous and well-readable. And here comes on of the trickiest thing of the streaming industry : state setter methods.
The two most common examples are the pause/resume, and mute/unmute methods for streams. Which is the best approach?
Let’s see what macromedia did in for play/pause :
Flash before player 9
stream.pause( )
stream.resume( )
they added a new method in player 9
stream.togglePause( )
has meaning, but you have to store the present state of the stream, that is additional code
or with muting a component
audio.mute( )
audio.unmute( )
how would a toggle look like?
audio.toggleMute( )
My components choice are the state setter methods :
stream.setPauseState( flag );
audio.setMuteState( flag );
The kickback of state setter methods that you can jumble up states in case of a badly named method. Sometimes separate on/off methods are also good.
It’s up to you
MilGra
|
2009-03-15 Data UI component hell
|
When i was a young programmer, and i had to make some data holder ui component, for example, an userlist, i simply created a component which had two methods for manipulation :
addUserItem( id , nick )
removeUserItem( id , nick )
And the component itself created and stored every item object, and also contained the routines for displaying the wanted region of elements, and listened for click events, and dispatched every added info with these events.
After my application needed more slightly different data UI components, i realized that its not a good idea to make too specialized components, because they have a lot of functionality in common, the only thing what differs are the items, and the data needed for the items.
So i started to think. What if i create a table component which accepts pre-made items, and it just displays and scrolls them, and all item-related stuff is up on me, disconnected from the component logic.
addItem( item )
removeItem( item )
It was much better, but it still was a pain. If i had more items, than i had to iterate trough arrays to add them to the component, or if i had to remove plenty of items, then it was also painful. So i’ve added two more functions
addItems( itemList )
removeItems( itemList )
But it still wasn’t satisfying, after months i knew that it could be simpler. Its not good that i need four functions. I’m adding and removing single and multiple elements, and the component is maintaining an internal array of elements. What if i simply give an array of items to be displayed?
displayItems( itemList )
So the component doesn’t have items any more, it just displays a list of items. I don’t believe in universal classes, components and frameworks, but this is one case which seems to be the perfect solution.
MilGra
|
2009-03-11 Balance of method count and parameter count
|
As a young and ambitious programmer, i often faced the problem of the fragile balance between methods and parameters, and even parameter complexity.
Let’s say we have to create a server-client application system realizing a chat application with different usertypes. If there are admins and guests, and i want to keep userlist management simple, i can say that i need four functions :
addAdmin( nick )
removeAdmin( nick )
addGuest( nick )
removeGuest( nick )
and i also have to invoke them from the server side. So i have to touch my code eight times, which is way too much. And what if our customer wants more usertypes later? We should care about flexibility more. So what if we introduce an additional argument, called userType, and we can make our code and life much simpler.
addUser( type , nick )
removeUser( type , nick )
This seems much better now, and only four touches needed this way. But we shouldn’t be satisfied with this. What if we need more information about a user later? Ip, country, full name, e-mail address, phone number, gender and so on… ? Will we extend our definition with parameters like :
addUser( type , nick , ip , country , name , email, phone, gender );
But then i will always have to be aware of the sequence and types of tremendously lot parameters, and if i switch to server side, even the IDE won’t show me what parameters are needed, this is the perfect place for bugs and magic mistakes.
In my opinion, if a method needs two or more parameters, it’s nearly always a good practice to use a parameter object, which contains everything necessary. Method definition is simpler, and every language gives tools to iterate trough object keys and values easily.
So our present state is
addUser( infoObject )
removeUser( infoObject )
Can we advance this? If we have an information object, why don’t we simply put the method identifiers inside, so we will need only one client side method and one server side call. You can say that this is a fall from one extreme to another.
It would be right if we were doing client side or server side code only, but we are talking about a communication link between a server and a client, and we have to keep it clean, fast and simple. If we have one method only, the error possibilites are reduced to this point, we surely get all data on both side, and message sorting and sending to their proper places are on us. And luckily, this can be done with a simple switch..case statement, and we can easily monitor and catch invalid calls and parameters without annoying exceptions.
So our final state is
invokeMethod( infoObject )
where infoObject has
- id - value
- param1 - value1
- param2 - value2
- param3 - value3
so in case of adding an admin, it can be
- id - addUser
- type - admin
- nick - adman
- ip - 0.0.0.0
- email
- etc
One level objects are great. But sometimes you may need more complex information objects for parameters, or for parameters for parameters, well, in this case you have to be careful.
Long story short, keeping method and parameter count minimal is good in most cases. But never forget the golden rule : There is no such thing like universal solution. A new situation needs a new solution.
In the next post i will talk about cases when you may need more methods
MilGra
|
| more recent posts>>
|