10 comments

1

I design depending on what the program needs to do.

  • The code is written in such a way that changes going to be located in one file if possible.
  • The code is fault tolerant that if something happens it gets to a predictable state even try to recover.
  • The code is written in such a way that it can be very easily tested by testers without need of unit tests or special tools.
  • The code is written in such a way that it can be hooked into a UI but does not require one to run.
  • The code is written in such a way that when it encounters a bug then it does not bring down the complete application.
  • The code is written in such a way that it is intuitively User understandable and therefore I waste way less time in creating documents.
  • The code is written in such a way that it optimizes the program flow first. If it needs speed then I design it for speed, when it needs reliability then I design it for realizability. If it needs user friendliness then I design it for user friendliness.

Now a wakeup call for anyone that uses design patterns! Design patterns sucks because it prevents you to create agile and easy to use/test programs.

0

All these criterias sound absolutely sensible. Your last sentence raises a question mark for me. Let me ask you two questions:

  1. If you don't use well proved best practices in your program, how do you make it understandable for people that are not you?
  2. I don't get the point why design patterns are against testability. Could you shed some light for me?
2

Don't ever tell what I say now in a hiring process! HR prefers you to use the "BINGO words" not what will make your project a success.

If you don't use well proved best practices in your program, how do you make it understandable for people that are not you?

Easy: the code looks very natural and reflects what you try to create

1- Design patterns are based on designs from good developers that solved a certain problem very well. However when academics try to quantity these design patterns and shoehorn them into some abstract way to designing software you basically killed the reason why this pattern was design in the first place: "To solve a specific problem and make your code readable"

The big problem now is that a lot of autistic idiot managers took a book learned the design patterns and for everyone to use these miracle saving solutions. And what make things worse every manager is now copying these other autistic idiot mangers without questioning if these design patterns makes stuff better or cause more problems than they solve.

Now why do people think that design patterns are miracle things? Because they are so used to bad design that no one knows anymore what a well design program look like. Developers are so used to see design patterns that no no notices that these are crippled programs.

2- This one is hard to explain if you never grew up with code that is elegant in design. Everybody has forgotten how to program. But I challenge you to kick out design patterns and unit tests, kick out agile development. And develop your program from scratch. Force your creativity as a develop to find new ways to solve a problem. Develop in such a way that your code becomes part of intellisense.

The key here is to force your inner developers creativity, break the development rules because you can.

If you are curious. If you could give an example of (short) design patterns then if I find time then I can convert it to something that is more elegant.

0

you are really passionated, I like that :-).

However when academics try to quantity these design patterns and shoehorn them into some abstract way to designing software you basically killed the reason why this pattern was design in the first place: "To solve a specific problem and make your code readable"

Let's say the measureability is a crucial and problematic point in software development. Classifying a developer is not easy. I understand why it is done, that doesn't necessarily mean it is done in a sensible way. This is pretty comparable to IQ tests.

Now why do people think that design patterns are miracle things? Because they are so used to bad design that no one knows anymore what a well design program look like. Developers are so used to see design patterns that no no notices that these are crippled programs.

I don't know if I would pass over the responsibility of misuse of design patterns to managers. I don't consider design patterns to be magic.

This one is hard to explain if you never grew up with code that is elegant in design. Everybody has forgotten how to program. But I challenge you to kick out design patterns and unit tests, kick out agile development. And develop your program from scratch. Force your creativity as a develop to find new ways to solve a problem. Develop in such a way that your code becomes part of intellisense.

Actually I did all of that. When I started with programming it has been basic, then 8-bit assembler. You cannot be more close. The elegancy and beauty of perfect assembler code is pretty unmatched. Then moved on to VBA, VB6, .net, Java. I was searching for a long time after things that make programming more transparent, better understandable, and, this is the most important piece: Discussable on the same page. When you dont use design patterns due to you don't like how they are promoted, or you reinvent the wheel, you have one big problem: It is hard to get the same wording with other developers. That is main attraction of design patterns. A lot of developers will anyway use them, but they don't have the right name for it. That makes it easy.

There are reasons to kick out all the strategies in development, but I even do not do it "dirty" when it comes to prototypes. I am just faster using sensible strategies. BTW when I talk about design patterns I don't mean I blindly apply them.

Rules have been made for beginners, experts break the rules.

Let's give it a try, please think about how you would solve the following problem (architectural): Let's assume you have to do Excel automation. You need to take the following steps:

  • Open Excel Application
  • Load Excel Addins
  • Open 1...n workbooks
  • iterate through 1...N worksheets
  • set parameters
  • set formats
  • export the worksheets as pdf
  • close the workbooks
  • close the Excel Application

Be aware about the following constraints:

  • even in case of a misbehavior, it is not allowed to leave the Excel Application opened or a workbook being opened. System must be clean afterwards
  • Excel is an OLE Server. That means it is able to reject calls from you. If it does so, you need to be able to repeat your call to Excel.

Let me know your thoughts!

1

It would be nice if I know the scale of this project this is supposed to be. Are we talking about processing farms? Or are we talking about a single application that does these steps? Is it a batch script or is if a C# application? Does it run on servers without UI or just user PC's where the user can click on close when it messes up? Where do I get these source files from and where do the generated pdf files have to end up to?

Can I do the job without relying on OLE because the source files are in text XML? Not having to rely on an OLE server and processing XML content is way faster and controllable than using an OLE server.

I was already writing down a large scale solution until I realized that you are probably talking about a simple application. I am a C# developer, Batch script is not my specialty but heck why not. :-)

0

These are good questions!

Can I do the job without relying on OLE because the source files are in text XML? Not having to rely on an OLE server and processing XML content is way faster and controllable than using an OLE server.

Of course this should be a scalable solution, but we should use OLE. This is for one good reason: You can build up Excel workbooks with XML, but you cannot calculate, change pivot table field values for filtering, and the only application that is capable of rendering Excel->Pdf pretty well is the Excel application itself. So you need to work with "real" Excel application.

Are we talking about processing farms? Or are we talking about a single application that does these steps?

We are talking about having the possibility of running multiple Excel instances side by side on one machine while it should be possible to have multiple machines running.

Is it a batch script or is if a C# application?

It should be a c# application. There are some PIAs for Excel that are pretty good to be used

Does it run on servers without UI or just user PC's where the user can click on close when it messes up?

Let's assume we don't take care about any user interfaces and this is just an engine processing workbooks.

Where do I get these source files from and where do the generated pdf files have to end up to?

Let's assume it is not important. You may choose whatever is appropriate.

I am really interested in the overall architecture that you are going to choose.

Anyway, enjoy the weekend :-)

1

I am in no way familiar with Excel automation but I would start with something like this.

What I do is start with something and observe how it behaves. Then I iterate through changes until find the most optimal code. This means that I will try different variations.

But before I can develop good code I must establish a base version that is simple and works. I don't care about fast or perfect, I must learn how Excel and OLE behaves, how it uses up memory, CPU, bottlenecks and how to recover from hanging first.

And most importantly the code should be readable. Note: I am doing this without C# just out of my head and I never developed for Excel ;-)

var excel=new Excel()
excel.Open("myExcel.xls");
excel.Close();

Stage 2

public Excel : IDisposable {
    public bool IsOpened {get; set;}
    public void Open(string fileToOpen) {
        ....
        IsOpened=true;
    }
    public void Close() {
        ...
        IsOpened=false;
      }
    void public Dispose(){
        if (IsOpened) {
            Close()
        }
    }
}

Stage 3 we get somethign like this:

using (var excel=new Excel()) {
    excel.Open("myExcel.xls");
    excel.Close();
}

Now we try a prototype not caring about bugs, naming or reliability. The goal is to have a concept, something that works just to find the weakness and flaws on this part

using Microsoft.Office.Interop.Excel;
public Excel : IDisposable {
    public bool IsOpened {get; set;}
    private Application exelHandle;
    private Workbook    workBook
    public void Open(string fileToOpen) {
           exelHandle = new Excel.Application();
           workBook = (Workbook)exelHandle.Workbooks.Open(fileToOpen, false, false, m_objOpt, m_objOpt,
                                                         m_objOpt, m_objOpt, m_objOpt, m_objOpt, m_objOpt,
                                                         m_objOpt, m_objOpt, m_objOpt, m_objOpt, m_objOpt);
        ....
        IsOpened=true;
    }
    public void Close() {
        ...
        if (wBook != null) workBook.Close(false, m_objOpt, m_objOpt);
        workBook=null;
        if (exelHandle!=null) exelHandle.Quit();
        exelHandle=null;
        IsOpened=false;
      }
    void public Dispose(){
        if (IsOpened) {
            Close()
        }
    }
}

I will continue in other posts (could take some time or days depending on my time I have)

But I think it is interesting to see my workflow.

Edit: Just a question Do you mean this:

* Open 1...n workbooks
* iterate through 1...N worksheets
* set parameters
* set formats

Or this

* Open 1...n workbooks
* iterate through 1...N worksheets
         * set parameters
         * set formats
0

Stage 2: use Disposable pattern incorrectly

0

You are completely right, I meant

  • Open 1...n workbooks
  • iterate through 1...N worksheets * set parameters * set formats

But wait. I wasn't talking about really implementing it. What I am interested in is the overall architecture. You talked about a replacement of design patterns - an alternative well known best practices that also accomplishes transparent, maintainable, extensible and understandable code. You really don't need to create a working system - I already implemented it ;-)

Let's discuss on architectural level, and only care about the how without the actual doing.

1

Update, when I started to take the challenge then I thought it would be simple but this simple example is behind the scenes pretty complicated. I don't think I can post this here on Voat nor have the time to create one. I estimate 3 working days for a first framework and then 2 more days to have a stable working version that can become the basis of anything direction you would like to take it.

In order to get a good basic frame you need to think about this.

  • When I get the excel file is it one fixed template? Or a series of templates?
  • Do the excel files come in pairs with the data and do I need to merge them?
  • Is the data to merge fixed and do I have different excel files to merge?
  • Do I have the merging data before the excel file? Or do I first need to load the Excel file and then determine what data I need from that file?
  • Do we have a limited number of data files and excel files? Can I preload both of them?
  • Can the data be already be preprocessed so that the merging takes minimal effort?
  • Is the import files source the same as the output file source?
  • Are the excel files huge? Os small size?
  • Are the excel files and data files constant or changes on the fly?
  • Do the cell data depend on each other?
  • Do the cell data cross different tabs?
  • Difference in file size? Bigger excel spread sheets need more time to load and save and can block smaller files that is waiting for the big one.
  • Order of processing, are the excel files to be processes in the correct sequence as they come in or can this be a random order.
  • The data to be inserted, Is it a simple push of data to known cells? Is it a search and replace of all cells?
  • Testing, how would the users test every stage?

I surely would start with a separation of the Excel specific logic and and the processing logic. Design classes for an Excel subpart so that each part can be easily used.

If the excel template files are constant than I could is something like this: We prevent reloading the excel template every single time, just copy it reducing hard disk bottle neck


var mainTemplate=new Excel()
var isSuccess=mainTemplate.Load("Template.xls", MaxRetry:6, DelaybetweenRetries: 500)
if (isSuccess) {
      var datafiles=new DataFiles()
      var isLoaded=dataFiles.Load();
      while (isLoaded) {
          var newDest=new Excel(mainTemplate);  // Copy constructor that copies from the template files)
          var isProcessed=dataProcesser.Process(newDest))
          if (isProcessed) newDest.Save("destination.pdf", FileType.PDF)
      }
}
if (isSuccess.Close(KillProcessIfNeeded:True))

If data is not a search and replace the something like this can happen:


var mainTemplate=new Excel()
var isSuccess=mainTemplate.Load("Template.xls", MaxRetry:6, DelaybetweenRetries: 500)
var newDest=new Excel(mainTemplate);  // Copy constructor that copies from the template files)
if (isSuccess) {
     var datafiles=new DataFiles()
     var isLoaded=dataFiles.Load();
      while (isLoaded) {
          var dataProcesser=new DataProcessor(;
          var isProcessed=dataProcesser.Process(newDest))
          if (isProcessed) newDest.Save("destination.pdf", FileType.PDF)
      }
}
if (isSuccess.Close(KillProcessIfNeeded:True))

I don't have time to get in this project deeper but it is very interesting to solve it for my future projects.