I have a project in which I am organizing my variables/tags using categories like "PartA", "PartB", "Data", "HMI", and of course the requisite "Debug".
So a few examples of random tags would be:
Debug.ReadWriteTimer
HMI.ReportViewerMode
Data.IndexResult
Data.ActiveDirectory
PartA.InspectionResult
But I have several variables that I am using across the program as logistical devices, such as counters, indices, and (non-debug) timers, that don't really fit in the the few categories that I listed above.
I've considered the following but none of those seem to fit either:
Global.tagname
Program.tagname
Devices.tagname
What is a clear and logical naming convention for program-level "tools" like these that would be instantly recognized by someone looking over the tag database for the first time?
(Context for the curious: this particular project is created using a machine vision software called Cognex Designer, which utilizes the C# language in an interface that is the illegitimate child of RSLogix and LabVIEW.)
misc, shortcut of miscellaneous, is/was often used to categorize items that couldn't be put in other categories.
This is if you must use a category, otherwise the lack of category perfectly describes the miscellaneous property of a variable.
I've decided to use "App", short for Application, as the category for these items. I believe it's clearer than "Program" and not easily confused with scope, like "Global", and the abbreviation will help alleviate confusion with .NET's Application object.
Related
So i have developed an application in vb.net but recently i came across the requisite of allowing multiple languages for it. I dont know if there is any 'common' way of doing this kind of things, but my approach to accomplish that is the following:
I'll need to search in the code for components, error messages and everything that is displayed in the GUI of the application to be translated.
Secondly i will create a class in which i'll store in memory a dictionary of everything that will be translated
after, i'll replace the stuff to be translated withing an entry of the dictionary
then when the application start i'll load the dictionary
later on, i'll replace the static dictionary and will load it in memory from the database
So for example, my dictionary class:
Dim dictionary As New Dictionary(Of String, String)
dictionary.Add("00011", "hello there!")
Somewhere in my code i'll replace:
mylabel.text = "hello there!"
With:
mylabel.text = dictionary.item("00011")
Later on i will, instead of having a static dictionary, create that dictionary getting the information from a database like this (and load it at the start of the application:
_______________________________________
word_code ### word_EN ### word_FR
_______________________________________
00011 ### hello there ### bonjour il
I will load the dictionary considering which language is selected.
I'm not very confortable with this approach and i have no idea if this is the right thing to do, but if so i have a couple of questions:
is a dictionary the best data-structure to do so?
will this be memory-heavy considering i'll have 1000 entries, 1m entries or 10m entries?
is there any logic and faster way of accomplish the same?
Thank you so much in advanced,
J
It's a common way of doing it - having a system name along side a language code being used to look up a translated value. However, generally speaking I'd only advice you to do this for something like system texts and smaller text segments.
The reason is that in for example CMS/ecommerce systems, pages with lots of text likely will need to be translated in a data model to support it to begin with; and then you already have the language division.
So in that situation, you're better off making a page structure with a translated data model where the detail will be language specific per language for your current website.
For example, you'll have a product -> product_detail where detail keeps the translated values for said product. Similar for article -> article_detail and so on.
But for general translations and system texts which needs to be displayed, it's a common way to do it.
And as you suggest yourself, structures like like dictionary would be a good structures to to make fast look ups and can be cached in the system so you do not need to retrieve them all the time.
Some ways you can expand on it, is by sub dividing your translations into sub groups; say you have an order page and a product page. Then you can have translations assigned to "product" and to "order" with a "common" group as well.
It will also make it easier to build smaller cache objects, extract less data from your data storage etc, so a page which only revolves around orders don't need to worry about product translations.
It will require memory, but unless you put entire CMS systems into the translations, it should be "minor".
I would however question a need of 10 million entities of translations and wonder whether or not your system actually requires that many and if it does, then maybe consider an alternate approach and whether it might be better to make multiple versions of the "page" to eliminate the need for translations.
I would also advice you to not use "00011" as a system code to begin, and go for a more "readable" version (like "hello") to ease the readability and maintainability of your code. Then if you want a 'system value' which is like "00011", it's easy to do a search/replace.
This is not a subjective question; I am mainly asking to see if structures are now deprecated or something in VB.NET.
It is also not generally a duplicate of a question asking when to use a structure or a class, as this is largely checking to see if such information has become outdated. Furthermore it is certainly not a duplicate of questions relating specifically to C#, as these are two different (albeit similar) languages. The difference between classes and structures is language-dependent, as can be demonstrated by VB.NET and C++.
In Visual Studio 2012, when creating a new VB.NET file, you get options for Module and Class, among other things, but there is no option for Structure. For instance:
If you simply select to add a new item, then the much more complete menu doesn't list it either:
This seems like an awfully big oversight, especially when there are meaningful differences between classes and structures in VB.NET, so I'm certainly suspicious that it's not really an oversight at all.
Are structures a deprecated practice now? Has the language been revised in some way that has made the difference between a structure and a class much more meaningless? Is there any technical or widely-held convention that I am unaware of here? Or is it just an oversight after all? Thanks.
EDIT
To make a long story short, my understanding is that, among one or two other things, structures tend to be more efficient for smaller amounts of code, and classes tend to be more efficient for larger amounts. This is because of differences between they ways that their memory is managed. Even though a lot of people always think in terms of classes in a language-agnostic kind of way, I thought there was a practice among fluent VB.NET developers to use structures as well.
No, structures are not deprecated. They have just never been on the Add Item list.
Which is probably because people haven't been willing to reserve a whole file for a single structure, preferring to put them in classes and modules. But you can if you want.
If you are concerned with class vs structure differences, you probably want to see Structs versus classes.
Just to add some more information... The type that you choose from the "Add" dialog only affects the initial template you get in the editor. It is perfectly valid to add a Class file, then edit it to turn it in to a structure, form, or even a module. Typically if you want to create something that isn't in the list you would choose "Code File" to get a blank document to customize as you want.
You can even create your own templates to add to that list. If you find yourself wanting to add a template for a structure you can do it fairly easily.
Here are some basic instructions on how to do that.
http://msdn.microsoft.com/en-us/library/tsyyf0yh.aspx
Some structure types like List<T>.Enumerator are used essentially the same way as objects, but a more common usage case for structures is as simple aggregate types which hold some data for the use of other types. The behavior of a type like KeyValuePair<TKey, TValue> is simply "Key and Value are properties of type TKey and TValue, which hold whatever outside code asked them to hold." While some companies' policies may require that every type reside within its own file and have its own associated documentation package, placing utility structures into a file with a package's static utility functions, static constants, etc. may make more sense than splitting them into separate files, especially if they don't have any substantial logic of their own.
Nothing is preventing a programmer from placing a structure into a file by itself, but the usage case was not considered sufficiently frequent to justify a special template for that purpose.
This is a generic question, I don't know if it belongs to Programming or StackOverflow.
I'm writing a litte simulation. Without going very deep into its details, consider that many kind of identities are involved. They correspond to Object since I'm using a OOP language.
There are Guys that inhabit the world simulated
There are Maps
A map has many Lots, that are pieces of land with some characteristics
There are Tribes (guys belong to tribes)
There is a generic class called Position to locate the elements
There are Bots in control of tribes that move guys around
There is a World that represents the world simulated
and so on.
If the simulated world was laid down as a database, the objects would be tables with lots of references, but in memory I have to use a different strategy. So, for example, a Tribe has an array of Guys as a property, The world has a, array of Bots, of Tribes, of Maps. A Map has a Dictionary whose key is a Position and whose value is a Lot. A Guy has a Position that is where he stands.
The way I lay down such connections is pretty much arbitrary. For example, I could have an array of Guys in the World, or an Array of guys per Lot (the guys standing on a piece of land), or an array of Guys per Bot (with the Guys controlled by the bot).
Doing so, I also have to pass around a lot of objects. For example, a Bot must have informations about the Map and opponent Guys to decide how to move its Guys.
As said, in a database I'd have a Guys table connected to the Lots table (indicating its position), to the Tribe table (indicating which Tribe it belongs to) and so it would also be easy to query "All the guys in Position [1, 5]". "All the Guys of Tribe 123". "All the Guys controlled by Bot B standing on the Lot b34 not belonging to the Tribe 456" and so on.
I've worked with APIs where to get the simplest information you had to make an instance of the CustomerContextCollection and pass it to CustomerQueryFactory to get back a CustomerInPlaceQuery to... When people criticize OOP and cite verbose abstractions that soon smell ridiculous, that's what I mean. I want to avoid such things and having to relay on deep abstractions and (anti pattern) abstract contexts.
The question is: what is the preferred, clean way to manage entities and collections of entities that are deeply linked in multiple ways?
It depends on your definition of "clean". In my case, I define clean as: I can implement desired behavior in an obvious, efficient manner.
Building OOP software is not a data modeling exercise. I'd suggest stepping back a little. What does each one of those objects actually do? What methods are you going to implement?
Just because "guys are in a lot" doesn't mean that the lot object needs a collection of guys; it only needs one if there are operations on a lot that affect all the guys in it. And even then, it doesn't necessarily need a collection of guys - it needs a way to get the guys in the lot. This may be an internally stored collection, but it could also be a simple method that calls back into the world to find guys matching a criteria. The implementation of that lookup should be transparent to anyone.
From the tenor of your questions, it seems like you're thinking of this from a "how do I generate reports" perspective. Step back and think of the behaviors you're trying to implement first.
Another thing I find extremely valuable is to differentiate between Entities and Values. Entities are objects where identity matters - you may have two guys, both named "Chris", but they are two different objects and remain distinct despite having the same "key". Values, on the other hand, act like ints. From your above list, Position sounds a lot like a value - Position(0,0) is Position(0,0) regardless of which chunk of memory (identity) those bits are stored in. The distinction has a bit effect on how you compare and store values vs. entities. For example, your Guy objects (entities) would store their Position as a simple member variable.
I've found a great reference for how to think about such things is Eric Evan's "Domain Driven Design" book. He's focused on business systems, but the discussions are very valuable for how you think about building OO systems in general I've found.
I would say that no 'true' answer exists to your core question -- a best way to manage collections of entities that are linked in multiple ways. It really depends on the kind of application (simulation) - here are some thoughts:
Is execution time important?
If this is the case, there is really no way around analyzing in which way your simulator will iterate over (query) the objects from the pool: sketch out the basic simulation loop and check what kind of events will require to iterate over what kind of model entities (I assume you are developing a discrete-event simulation?). Then you should organize the data structures in a way that optimizes the most frequent/time-consuming events (as opposed to "laying down the connections arbitrarily"). Additionally, you may want to use special data structures (such as k-d trees) to organize entities with properties that you need to query often (e.g., position data). For some typical problems, e.g. collision detection, there is also a whole lot of approaches to solve them efficiently (so look for suitable libraries/frameworks, e.g. for multi-agent simulation).
How flexible do you want to make it?
If you really want to make it super-flexible and really don't want to decide on the hierarchy of the model entities, why not just use an in-memory database? As you already said, databases are easily applicable to your problem (and you can easily save the model state, which may also be useful).
How clean is clean enough?
If you want to be absolutely sure that the rest of your simulator is not affected by the design choices you make in regards of your model representation, hide it behind an interface (say, ModelWorld), which defines methods for all the types of queries your simulator may invoke (this is orthogonal to the second point and may help with the first point, i.e. figuring out what kind of access pattern your simulator exhibits). This allows you to change implementations easily, without affecting any other parts of the simulator code.
In a program that I'm responsible for, we want to start keeping track of milestones. These milestones are quite simple and consist of a unique identifier, the project they're assigned to, a description, and a date that they should be accomplished by (or not, if there's no concrete due date).
We use a slightly modified Model-View-Presenter architecture, and currently I'm passing this list around through the presenters, but it seems fairly clunky, so I was wondering:
What's the best way to make this list available to all the presenters/views that need it?
We're using VB.NET 3.5, and I was toying with the idea of making this a shared property of the main presenter, but it does seem like that adds some unnecessary coupling.
I agree with Oded about keeping it as you have it, but if you insist on having it the way you describe, you could consider implementing it (the collection) as a singleton.
Have a read through this article
I understand the three basic failures in EAV, namely that it takes a lot of work to reassemble the data. However, I want a database where I can add custom fields. A lot of people say that Virtuemart allows custom fields but without using an EAV database structure. Can someone explain how this can be done or provide links?
I believe they store custom fields in a chunk of XML or YAML or other domain-specific language.
Basically, they use Martin Fowler's Serialized LOB pattern.
This makes it hard to use SQL expressions to query the custom attributes. You have to fetch the whole row back into your application and parse out the custom attributes. But this is no worse than the pain caused by EAV.
See http://web.archive.org/web/20110709125812/http://sankuru.biz/en/blog/8-joomla-configuration-issues/35-the-cck-buzz-content-creation-kit-and-the-eav-problem.html
Virtuemart and CCK
Virtuemart (VM) custom user fields are
CCK-style, but do not rely on EAV.
Therefore, they are very usable, and
useful. I do recommend their use.
VM product types are also CCK-style,
but unfortunately do rely on EAV.
Therefore, I avoid VM product types
like the plague. Instead, I just
manually create additional fields in
the product record.
The VM attribute system (simple,
custom, advanced) is actually too
underpowered to be considered CCK
grade.
A good improvement to VM, would
consist in rephrasing the VM product
types and attributes to non-EAV
CCK-style custom fields (and therefore
make them work more like the VM custom
user fields).