|
And now it becomes a design issue, do you store the DW data in a denormalised structure (this is standard practice for a DW) do you then write 2 distinct reports targeting each system.
How often do you transfer data to the DW?
How often do you purge data from the production system?
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I have setup consisting of several devices that can communicate through high-speed buses. The following devices exist:
A. 1 grandparent.
B. The grandparent has 5 children. I will denote these the parents.
C. Each parent has 1 child. I will denote these the children.
The grandparent can talk directly to the parents and the parents can talk directly to the grandparent and their own child. Furthermore, the grandparent can also talk to its grandchilden, but it needs to do so via the parent and likewise, the children can talk to the grandparent, but needs to go through its parent. I need to visualize in a table (C# DataGridView) how packets are going back and forth and make it easy to understand what's going on in the system at any given time. All devices has a debug UART and I can modify the source code in all the devices to get the debug messages I need. I'm currently writing a terminal application that can handle several COM ports. I was thinking that the grandparent always logs its data with 0 indentation, parent 1 logs with 4 spaces indentation, parent 2 logs with 8 spaces indentation, etc. Then I was thinking about showing the same packet as it progresses through the chain in the same color everywhere. Whenever a log message contains the word error, then I will display that row in red. If something is purely information, but not a packet, then I was thinking about showing that with a specific pattern style (similar to Excel "Format Cell" -> "Fill" -> "Pattern Style"). Does anybody have any comments or suggestions on this? Is there something I can google image search to get some inspiration?
|
|
|
|
|
I don't know what limitations you face when displaying this, but a message sequence chart[^] might work. I generate simple ASCII versions of them in a session processing framework that I developed, and I was impressed by this article[^], which might help you generate professional looking ones.
|
|
|
|
|
Wow, that's impressive! I'm one layer above, though, so I'm only logging whether it's a read/write and the address and number of registers. I don't log the reply packets, but if I don't get a reply packet then it gets logged as a critical error.
|
|
|
|
|
If the system is idle for long time then can we find this using the mouse movement or mouse click event the system's idle time.
|
|
|
|
|
|
I'm working on a Windows forms application that shows a list of PDFs in a given folder, with a toolbar with buttons that carry out operations on the list of PDFs. The form has a data grid view that takes as its data source a list (PDFlist) of objects (PDFentry) that have properties file name, file date, file size, etc. (Like Windows Explorer).
Because the operations are carried out on the entire list of PDFs, the code for the various operations necessarily loops through PDFlist, acting on each item. That's a lot of code, so form.cs is pretty big (900+ lines). It seemed to me that PDFlist could be its own class, inheriting from List and adding methods for the various operations. Then form.cs would just have a line that said PDFlist.Compress(), or PDFlist.Print(), or whatever the operation was.
But then the red flag was that there's only ever one instance of PDFlist. It's not a singleton in the sense that I don't have to prevent a second instance from being created. It's just that the application only uses one PDFlist throughout.
Would this be a case where a static class is appropriate?
|
|
|
|
|
One thing I have painfully learned is that while a static may work now, at some point you will end up using it from multiple threads and then all hell will break loose. If the class has any state, try not to make is global or thread static.
Also, these types of errors are some of the worse to debug.
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
RobertSF wrote: Would this be a case where a static class is appropriate?
No, a normal class is what would be appropriate. Whether you have one instance of the class or one thousand is irrelevant.
|
|
|
|
|
I have (static) "adapter" classes; similar in concept to a "table adapter" and its "fill" (a table) method, etc.
Static, because often there is no instance data other than the object being operated on. Just makes calls simpler when you don't need a instance reference to an adapter.
Adapters, for me, often make more sense than adding methods to an object, which then operate on "itself".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
|
What is Google[^]?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I'm keeping an eye on this user. Seems potentially spammy to me.
|
|
|
|
|
Class to leave test traits representing handling failures in a live build so long as everybody uses the liveliest google build but complains only about other multinationals like Mozilla when stuff is already messing with their 'logs'.
------
class NoddyXmlStorageBuilder : bust::maybeSingletonInstancesNeverWereThing
{
NoddyXmlStorageBuilder setNest(std::string what, IRegex why) = 0;
IRegex get(std::exception why_not) = 0;
}
class BittenByGoogle : bust::disable_when<NoddyXmlStorageBuilder::isVisualOnly>
{
// add your more classy methods here
// be careful as live testing traits
// will end up dead on wire someplace.
void seedRandomLogFile(std::string someGarbage, enum DebugLevel) = 0;
bool hasBeenBitten() { return true; }
}
|
|
|
|
|
What has this got to do with this thread? Was this meant to be in reply to something else?
|
|
|
|
|
Somebody mislabeled an hyperlink - so I wrote a code joke about log-directory trashing and neophytes views on storage selection.
|
|
|
|
|
Our company is currently running .NET version 4.5 and using VB as the back-sript language. All of our forms are basically using the general ASP.NET forms methods. In other words we are not taking advantage of the any of the MVC core methods.
We are getting ready to start our new design process and wanted to get some recommendations on what framework and mythologies/C# version/database methods/Web UI methods, to use in our new design.
Any advice would be grateful,
Thanks,
Steven
|
|
|
|
|
The answer is: It Depends!
What skills does your team have / how much new learning are they able to do?
Are you intending to run the old stuff concurrently with the new stuff or is it a big bang approach?
What is the problem domain? That will dictate what are the best tools for the job
Are you willing to risk leading edge (which may be buggy) or do you want trailing edge (which may cause upgrade issues in the future) or do you want to play it safe (e.g. go with the next-to-latest version)?
Who are your clients / customers? What will they be most comfortable using?
Are there off-the-shelf packages that can do what you want which could save you a lot of development time?
Stevey T wrote: recommendations on what framework and mythologies/C# version/database methods/Web UI methods, to use
Do not use mythologies: they are not real!
|
|
|
|
|
Hello,
In my company we had a system on .net framework platform. That was made from an orchestator, different rest API services on top of a monolithic oracle DB. With a huge plsql library.
We used distributed transaction for the operation (import of data). Because of the rollback possibilities if one request did fail e.t.c. And used a orchestrator in front of the rest API services (micro services) that organized the different requests all in one transaction.
We had to upgrade the system to .net core.
But .net core don't support DTC anymore !
Have anyone had a similar situation, and what what did you do about it?
Or do anyone have any comments to this issue/problem.? That if one request fails in a
big operation of many requests the database data will not be consistent, if no rollback is done.
When we use many "micro"services on top of one monolithic database.
BR
|
|
|
|
|
I think a DTC implies "multiple" "micro services".
A transaction that spans multiple databases is not what I would can micro.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
We are thinking of building an internal Kaggle like platform to run Hackathons in our company. I am wondering what would be the best technologies to use for this and how to go about building such a site. Any help appreciated. Thanks.
|
|
|
|
|
So we need to first visit Kaggle to know what you're talking about? And then we come back here to ask you questions about Kaggle?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
|
I have always had the view that duplication is bad. There are always exceptions, but most of the time I it seems bad to me. Unit tests are one are where I tolerate it more but in production code it's something that I rarely find desirable.
Some people duplicate things two or three times and only eliminate the duplication on the third or fourth time. I really can't understand why somebody would blindly follow this rule. I understand the argument that we may not know how to refactor something if there are aren't enough instances of the duplication but I find that it is rarely the case. At least if you don't know how best to refactor something then keep it simple. The rule seems crazy as why would you do something if you know it's bad? Eliminating duplication is usually quick and, in my opinion, usually makes things much easier to read, particularly when you have half as much code to read/understand.
As an example, imagine we want to format a number as a currency. We could have the following
x.ToString ("£0.##")
Having it once seems fine, but not really more than once. Surely, as a very simple refactor, something like the following would be better?
Format.AsCurrency(x)
Surely the time saved by the readability would outweigh the code of writing it and it solves the problems of duplication.
Deliberately duplicating code doesn't make much sense to me, but maybe I've been working with people who have taken things a bit too far?
|
|
|
|
|
The principle of Do not Repeat Yourself (DRY) is one of those areas that is taken too far by some code zealots. Let's take your ToString example here, you notice after a couple of times that you have the same ToString code so you decide to introduce an AsCurrency method. That seems straightforward enough, but you're working in a large codebase so you don't notice that the same logic has been added in pieces of the code that you don't visit. Worse still, somebody has done this elsewhere:
Then there was that piece of code which looks like this.<pre>public class FormatConstants
{
public const string GBP = "£0.##"l
}
...
return myItem.ToString(FormatConstants.GBP);
...What we're seeing here is that others have attempted to avoid repeating code with varying degrees of success. In all of these cases, there is an element of repeated code because differnt people have taken different approaches to to avoid repeating code. Even if the code doesn't look exactly the same, you are repeating the intent of the code. Now you have introduced yet another way to represent this same conversion. In six months time, someone else comes along and has to add a currency ToString in a few places so they refactor their code to avoid adding repeated code. If you're lucky, they have looked through the codebase looking for other places that does the conversion and picks an already written one; if they've searched using ToString("£0.##") then they might not have found the match so they end up adding yet another new way of formatting this one item. What has happened here is that the search to remove duplication has ended up creating a mess - and this is just with a simple example.
The bottom line is, DRY is a great principle and one that you should try to stick to if it makes sense but you have to accept that, in some cases, you aren't going to achieve it and you shouldn't beat yourself up over it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
