Hi, I am playing around with the idea of using hashing algorithms to store private data in the cloud. I recon it should be doable on most client platforms, because of the availability of hashing algorithms. - Each blob of data will have its own unique salt associated. - A password + salt is used to create a hash (only salt leaves the client). - The hash is used to encode the data in a rather simple manner. - The encoded data + salt + algorithm version is to be stored in the cloud. The hash can be used to decode the encoded data again. The algorith implementation is here: ARosettaStoneV1.java[^] Here is a unit test: RosettaStoneV1Test.java[^] As an example the unit test can produce:

quebird.brokenclouds.core.unit.stones.v1.RosettaStoneV1Test@37bba400.testEncodeAndDecode():
#0: MD5 + UTF-8 on 'Hello World! Hellø Wørld! 0123456789 §$!#€%&/()=?+´`¨^*'-_.:,;<>'
encode: --- START --- [algorithm=BC1+MD5]
encode: salt[length=36] = 49 52 102 50 53 99 102 101 45 48 50 101 56 45 52 50 53 97 45 97 48 52 50 45 100 98 50 98 50 52 100 97 49 51 57 53
encode: data[length=71] = 72 101 108 108 111 32 87 111 114 108 100 33 32 72 101 108 108 -61 -72 32 87 -61 -72 114 108 100 33 32 48 49 50 51 52 53 54 55 56 57 32 -62 -89 36 33 35 -30 -126 -84 37 38 47 40 41 61 63 43 -62 -76 96 -62 -88 94 42 39 45 95 46 58 44 59 60 62
encode: hash[length=16] = 37 5 88 33 -2 -28 58 -32 71 27 119 -120 22 -87 -91 -2
encode: padding[length=16] = 84 24 -28 -92 25 61 -97 -27 125 -98 71 -57 43 24 -98 100
encode: output[length=88] = 0 0 0 0 0 0 0 71 -87 79 10 -37 4 109 54 -115 -15 -121 106 109 -71 -60 106 -111 -88 82 -41 -104 -89 85 70 65 -38 127 49 -111 -77 16 -56 -14 -85 -94 81 -104 29 54 -8 88 43 63 35 89 -18 -114 58 90 48 -94 -52 57 35 59 116 74 -45 123 43 75 -5 -128 52 101 -95 52 -118 27 32 57 83 77 72 -1 123 -124 95 -110 51 120
encode: --- END --- [algorith

A year ago I had a similar problem. We should save requests on a server and each request had an id Guid/UUID. The solution turned out to be simple and fine. We simply wrote each cipher (in the guid) as a folder. That meant we got a folder hierarchy 32 deep with 16 branches on each level. Now one should think that it would have a terrible performance, but it actually was quite fast on linux with a solid state drive. Another benefit was that maintenance e.g. backup was easy with this solution. Maybe you could try something similar.

Yes. If C++ was a game I would call it a tad unforgiving :-)

Well, by not consistent I mean that you can end up with compiler accepted code, but it is unknown what it will do. The "dreaded diamond" refers to the situation where class C inherits from 2 classes B1 & B2 that both inherits the same base A. C will have 2 copies of all fields from A and at runtime it is undefined which copy you address.

Hi, Be aware that Gang of Four might not be the best book to start with. Browse the ratings on books that use language/modeling that is relevant to you. Be aware that one man's pattern is another man's anti-pattern. Sell Singletons to your enemies and give Observers to your friends. When you do dig into the Gang of Four and/or other books, please note that they are all about splitting communication and data up in interfaces, abstract and concrete objects in a specific way. This is what object oriented design is all about. The patterns are different standard design solutions. EDIT: Forgot one. Please also notice that people "talks" patterns in different abstraction levels. Sometimes people refer to Intent of a pattern. Sometimes people refer to a standard design code solution. People focused on Intent will claim that an anti-pattern is nonsense. People focused on code solutions will claim that Singleton is an anti-pattern. Confused? Good, start reading ;)

Usually there is a Profile page. On each computer add the other computer as a Friend.

Hi, Thank you for the blog link. You propose what is called mixin, which is really the go to solution to avoid bloated inheritance hierarchies. The good thing about mixin of Subject is that you hide functionality and avoids to duplicate the code in Subject. The bad thing is that you still need to duplicate the code that calls Subject aka relaying. DI with mixin is also good since you make the dependency known to the outside. This opens up for implementation replacement from the outside and gives better transparency. However, Uncle Bob really wants to hide stuff and use inheritance to avoid ANY code duplication and he can't do that in a single inheritance language. I love interfaces because they form a specification layer without any implementation details. I love abstract classes because they can be implementation templates for concrete classes. I do not want to mix the 2 concerns - at all. And it IS a tad annoying when you need add mixin in you abstract classes to avoid code duplication. I wouldn't mind multiple inheritance, if the language/compiler could manage diamonds in a consistent and obvious way (No, C++ doesn't). The class hierarchy is however implementation - not specification (IMHO). Uncle Bob doesn't address that view on the interface keyword.... and I am not sure the interface keyword had that view in mind when invented.

Hi, Since a robot is a real-time system, I wouldn't want to mix it directly into a web server. I would make an application in C# or Java with a dedicated socket for communication with the robot. This application can continuously communicate with the robot - read states and send commands. When that is in place, you can do use a database or the file system to pass data to and from a webserver. In this way you have the application in control of when to read a command from a client, when to send the command to the robot and when to sample the states of the robot. In a typical web servers everything is request based. A request is initiated by the client and your code is basically a method call that has to return as fast as possible. It might be easy at start, but it is a poor way to monitor a robot. As an example it becomes a difficult task to track the robot and document where the robot was and then deduce why it did as it did. I would let a standalone application dump the robot's state to a file system periodically and let it check the file system for the next command to send. In this way - if it is made flexible enough - you can have a folder with commands that takes your robot for a spin and produces a folder with its monitored states. If it fails, you can redo the experiment after changing what not on the robot, and you will have all data stored in the file system for your report. Afterwards you can make a web server page that reads/writes the file system. Kind Regards, Keld Ølykke

In Java I use the log.Log(Level.type, message) and In C# I use the log.LogWarning(message) or another. I find it pretty annoying in Java. They clearly made this better choice - better choice in relation to design e.g extensibility and maintainability. However, I need to work more with the Editor when writing this (more choices and Level import). In this case I would do as Java does, but also add most common usages e.g. LogDebug, LogWarning, LogError, etc. I guess it also is worth to consider how many options the enum will represent. The answer to this question might not be the same for "small" enums and "large" enums. I like this question btw. Another question, is whether to use enums or classes as arguments, but ... that is another question ;)

Most def. Hav fun!

Hi, I would use something like Strategy[^] to make different polling implementations. If a strategy finds something, I would let it create a Command[^] that can be executed by a thread. A Command can hold the data and have its own implementation. All Strategy and Command implementations regarding a technology e.g. mailing could go into its own package/assembly and get wired to a common execution platform at start-up. I hope it makes sense. Kind Regards, Keld Ølykke

Hi Kim, It is a bit difficult to give you some concrete advice, but here are my thoughts. I think they are classic 3 tier'ish. The easiest is the lower layer aka the data layer e.g. a simple API that stores data types in a storage (memory, disk, db, whatnot). This can certainly be within its own project (with its own unit tests) - it doesn't need commands or similar. For abstract data classes, etc. I prob. would make a "Core" namespace within this project. Another easy layer is the top layer aka the UI layer. Whether or not you tie the Application together with the UI layer in 1 assembly/package is a flexibility matter. In any case I would probably make a "Core" namespace within this layer too, but it has nothing to do with the data layer classes - only the UI. The hardest part is how you design control from the top layer to the data layer and how the top layer is updated indirectly by updates in the data layer. In MVC its the C, in SOA it is the services. I would create a middle layer aka the service layer that knows the data layer, but doesn't know the UI layer. In here you can make a lot of Controllers e.g. Commands that modifies the data layer. If you have a pull design, you can make some poll/query commands too. If you have a push design, you can register a general listener pattern that the UI layer can use, or fire commands going upwards to be consumed by the UI layer (not so popular in these client-server days). This middle layer also will have its own "Core" namespace with abstract Commands and whatnot. In above way you have a very clean division. It is pretty simple to avoid dependencies from the data layer to others, and it is doable to avoid a dependency from the control layer to the UI layer. One thing to consider is, if the UI layer should have direct access to the data layer. I find this decision hard to make - many cons and pros. If it makes sense for you to have a common assembly then go make that and let the 3 layers depend on that. Otherwise, just pull in logging, etc. in each layer. A common layer can easily mud your clean dependencies; before you know it there is a utility class that knows how to calculate some business data and it is used by both the UI and the Data layer. I hope it makes sense and triggered some thoughts. Kind Regards, Keld Ølykke

Hi, You are welcome. Maybe you should post the runnable code, if you think it will help people. "but what do you mean by the following: - (derived class) always call base in overriden virtual method/property?" Inheritance in OOP is relatively loose. The only thing you can be certain about is that constructors are chained e.g. new Y() will call the constructor of Y that as its first statement will call the constructor of A, etc.... all the way up til the contructor of Object. You can then have your constructor code in different implementation called on the way back from Object. For all other methods/properties no such guarantee exists. In other words it is optional to call a base-method, which makes it pretty hard to manage private fields in the base class :) So these 2 go together: ----------------- - (abstract class) always expect virtual methods/properties to be called by derived classes - (derived class) always call base in overriden virtual method/property ----------------- It is just 2 calling convention rules that mimic the constructor chaining for all virtual methods. In this way we can design interdependency between A and X - even though the language supports that you can avoid calling base methods/properties. I hope it makes sense... otherwise I can elaborate. Thx for the nice link, btw. Kind Regards, Keld Ølykke

Hi, 1) With an abstract class A you can define re-usable implementation for derived classes. This is a way of removing duplicate code in multiple derived classes. 2) With an abstract class you can defer implementation to derived classes e.g. defining abtract methods or properties. Why would you do that? Well you can call the abtract definition from implementation in the abstract class. 3) With an abstract class you can let implementation code be extended via overrides 4) With an abstract class you can declare collections of the abstract class, but add derived classes to the collection. I will try to make an example to illustrate above features:

abstract class A
{
// 2) A doesn't store the label content - a derived must
abstract string Label {get;};

string ToLabel()
{
// 1) Implementation centralized - not in all derived classes
return this.Label;
}

// 3) implementation that can be extended or even replaced
virtual void Writeline()
{
Console.Out.Writeline();
}
}

class X : A
{
// 2) A says I must do this - I at least choose the content
override string Label{ get{ return "I am X!"; }}

}

class Y : A
{
// 2) A says I must do this - I at least choose the content
override string Label{ get{ return "Me is Y!"; }}

// 3) optionally extending implementation in abstract class
override void Writeline()
{
Console.Out.Writeline(">>>"); // extra before base
base.Writeline();
Console.Out.Writeline("<<<"); // extra after base
}
}

void SomeCode()
{
// 4) Polymorphism - declaring a collection of abstract classes but adding instances of derived classes
List as = new List();
as.Add(new X());
as.Add(new Y());
foreach(A a in as) // 4 - accessing abstract implementation
{
Console.Out.Writeline(a.ToLabel); // 4 - no branching on implementation e.g. typeof(X) or typeof(Y)
}
}

Lots of patterns make use of abstract classes e.g. http://en.wikipedia.org/wiki/Abstract_factory_pattern[^] and http://en.wikipedia.org/wiki/Composite_pattern[^]. Try play around with it and the different ways of calling up or down between abstract and con

Hi, I have asked "Which Software Patterns makes your libs/apps testable?" here[^] At the bottom you will find a nice short list of patterns/principles to use. Kind Regards, Keld Ølykke

Hi, If you are in visual studio and want to get your hands dirty, you can take a look at A built-in system for code generation: http://msdn.microsoft.com/en-us/library/vstudio/bb126445.aspx[^] The built-in system for addins (you can write your own addin that can write/edit/delete files in an open solution): Visual Studio Add Ins - In Depth[^] Kind Regards, Keld Ølykke

To me it sounds like you are in too deep. I have difficulties seeing a working architecture in your proposed algorithm, but then again I am not a web guru. The "algorithm" you describe requires incremental development - that is - to investigate, try, get wiser, change and adapt numerous times. It might be a bit too complicated for a single forum post. You might want to hook up with a programmer that knows about browser code, web and security. Otherwise, it might be a long road for before you can deliver or find out that you can't. Please notice that this is just a proposed guidance for you based on my perception of your post information. It is by no means meant to be disrespectful. Kind Regards, Keld Ølykke

Hi Marc, When a client sends a GET request to a socket the socket returns a byte array. The byte array can just be the content of a html-page; a html that on Apache would be a file, but in your case is hard coded by the java server. Have a look at this: http://cs.au.dk/~amoeller/WWW/javaweb/server.html[^] Whenever a client sends you a request, you can use the relative url and/or parameters to decide what kind of data the client needs. You then return a byte array that represents that need. Please notice that you can return embedded javascript that uses google chart to display data. The processing of the byte array is done client-side, so your server code do not need to be expensive in processing terms. I hope it helps. Kind Regards, Keld Ølykke

Hi Thomas, I have never worked with 100+ dll's, but works for me is to have a build/bin folder that contains all dll's. I use NAnt to clean that folder, copy 3rd parties dll's there and to build the project dll's into that folder as well. I hookup visual studio with relative paths to that build/bin folder too. That ensures me that a dll only exists in 1 version e.g. log4net.dll is copied by nant to the build/bin folder, so when visual studio builds into its project temp folder it copies the version of log4net.dll from the build/bin folder. It might be an idea to have all visual studio projects build into 1 folder too, but I do not have much experience with that. Maybe another can guide you on that. Kind Regards, Keld Ølykke

Yes, indeed I think your example is the way to use strong name authentication of assemblies as a windows user. Whether it is easier than MD5 checks of downloaded files is another discussion. Btw. I wonder if this possibility is used by IT staff when managing shared workstations, or what other cases could be. I know there is some identity management when running Azure apps - don't know if it is linked to strong name signing. Would make sense though. Kind Regards, Keld Ølykke