General Discussion

[Abhas]

You got that Spot on Kshitiz. Sohum, I think we need to tone down a bit, and try to do the basic stuff 1st. Once we get started, we can move on to bigger things.

 

[sohum]

You got that Spot on Kshitiz. Sohum, I think we need to tone down a bit, and try to do the basic stuff 1st. Once we get started, we can move on to bigger things.

I don't think the DB programming is holding us back. I think it is a lack of a proper structure, which is my fault. It seems like our knowledge of OOP is widely variable, so I will try and get a design down for everything except UI (which I will NOT be doing ). That way, at least, you all will have a concrete idea of what to do.

As I told Kshitiz on MSN yesterday, the goal is that apart from the Backend team, no one should know what ODBC is.

This paradigm of programming is called "interface-driven" programming. Let me explain it to you here.

An interface is like a class, except that more than a class, it is a template. An interface cannot contain any variables or concrete methods. A concrete method is one that has its message body defined:

// concrete method
public void foo() {
  // do nothing
}

// abstract method
public void bar();
public abstract void bar();

The point of an interface is to develop a template so that objects interacting with other objects do not need each other to be developed. So, basically, an interface defines the functionality of the class. The power you then gain is that you can split your code up into intelligent modules and have different people work on different things.

ODBC is such an interface (from what I understand). This means that it connects to all sorts of different databases (MySQL, SQL Server, PostGre, etc.) but whoever is using ODBC does not need to know the implementation detail. If I am working on an application that needs to use a DB, but I haven't installed a DB yet or chosen what DB to use, I cannot sit around waiting for that decision. Instead, you code towards an interface. Suppose I have a DB interface that looks like this (and keep in mind that this is not a very smart interface, because it doesn't hide a lot of the DB code.

interface ISQLDBEngine {
  public DataSet ExecuteQuery(SQLString str);
  public void ExecuteVoidQuery(SQLString str);
}

Now somewhere along the line I finally decide that I want to use MySQL or something of that sort. Then someone can implement the following class:

class MySQLDBEngine : ISQLDBEngine {
  public DataSet ExecuteQuery(SQLString str) {
    // connect to the MySQL server
    // execute the query, etc...
  }

  ...
}

So you see, you can write the whole program without even knowing what DB to use! Of course, it'll be hard to test, which is why the interface needs to be intelligent. Imagine, instead, that you did not have a SQL-specific interface and instead had a pretty generic DB interface, and another interface for commands. Then you could build the commands and give it to the backend, which would take care of it.

The best part is while you were sitting around deciding what DB to use, you could actually implement the interfaces and store the data in memory instead of in a DB.

So the point of this whole spiel is as follows. The Backend will be providing interfaces to the rest of the components to function. Hence, the rest of the components should have no idea of what the Backend is doing. This even allows the Backend to perform caching, if it so sees fit. But that is not something the rest of the components need to know about. As it is, the Backend will be wrapping ODBC or using NHibernate, so the rest of the components don't need to know about that either.

I apologize that I have not put a lot of these ideas into paper or code, which is why you guys have been wondering what you should be doing now. Which is why one of the first things I had on the task list is to come up with a feature list. Secondly, design your system independently of the DB. By design, I mean think of classes and how they are related, etc.

If you have any questions, please let me know. I think I will finally have a table this weekend (maybe) so I may be able to get some work done.

sohummisra added 4 Minutes and 57 Seconds later...

--

Also, SVN is not working because my server broke. I think the HDD failed.

See the beauty of SVN? Everyone still has a working copy (or should if they updated recently).

 

[Kshitiz_Indian]

That's a pretty good post!

Unless the SVN requires more than just cPanel and FTP and the normal hosting stuff, I can provide SVN hosting!

Kshitiz_Indian added 1 Minutes and 6 Seconds later...

Also, I had one more idea. Maybe when every programmer writes some code, he could comment it with his name from the start and the beginning so we know when we read it, that who wrote the code?

 

[Kshitiz_Indian]

And another thing. Sohum, I've figured out the way to integrate C# and VB.NET - It can be done with the use of DLL's. If I make the interfaces and classes in a vb.net class library project, the same can be seamlessly integrated in the C# project, and I've manually checked that!

So I wanted to know, if my team's up for it, can we design the statistics engine in vb.net? Would it really make a difference?

 

[Isura]

Oh my my, I just read this thread. Pretty nice Sohum.

Infact, if you talk to Simon, I had come up with the idea quite ago in an MSN chat with Simon but I dropped it due to its vastness and me being only one at that time.

I would certainly like to help with this project. I'm pretty good at vb.net now, thanks to some recent projects like the scoreboard manipulator and Mod Manager, and especially AbBh and Colin. But I've seen you're not interested in vb.net.

My point is, these types of programs could be easily made in vb.net, dunno much about the flexibility part but modular programming in vb.net is very much possible. But then I don't think many people in the coding team know vb.net!

On the other hand of vb.net, I've started learning C++ too. I know some OOP concepts already, not many though, and I'm sure I'll grasp C++ pretty quickly. Visual I've heard is the IDE so that should not be a problem. So I would definitely like to be in the coding team

Good luck to all guys.

There is virtually no difference between C# and VB.net. You can do pretty much any OOP project in either language. Both support fully OOP and modular programming practices. They also both use the .net framework, which is more relevant than the language in a significant project. The reason Microsoft supports both is because the original VB has a huge following and culture (business types who use excel/vba/vb), and C/C++/Java have their own culture (geek types), so they didn't want to alienate a huge market of programmers.

Isura added 4 Minutes and 54 Seconds later...

There has been a complete overhaul in vb.net from vb6. VB has been converted into a complete OOP language. With vb.net there is no difference between VB and C#, leaving aside the syntax. Also, VB's IDE is better than C#'s.

But as most of the people are familiar with C#, we can use it.

Seconded. I prefer VB.net because of the IDE and I find "end if" etc easier to read than "}" all over my code

Isura added 23 Minutes and 25 Seconds later...

I have been working on a cricket simulator for the last few months. By far the hardest part is getting the simulator to spit out accurate results for each ball. I think that putting off the engine design is a mistake because it will take the longest to get right. It's better to do the engine design iteratively. Decide on what player characteristics to model (my program only uses batting skill (average balls per innings), batting strike rate (runs/100 balls), bowling skill (average balls per wicket) and bowling economy rate (runs/100 balls). Then I use these to get some probability distribution of the possible ball outcomes. My results are already pretty realistic, but I don't consider things like pitch and fatigue yet. The cycle to use is

write statistical tracking module
implement engine
test
tweak engine parameters (preferably without having to recompile) and/or improve engine algorithms
repeat

A bit of background. My plan was to make the simulator into a cricket management game like cricket captain. But now I'm getting a job in finance, and was planning to keep the project as a hobby. But since finding this thread, I want to help out with this project (software design/coding and whatever else you need). I am equally proficient in C# and VB.net, and have a good grasp of the design and technical issues in writing a cricket simulator.

Cliff Notes: I want to help with programming stuff

 

[sohum]

That's a pretty good post!

Unless the SVN requires more than just cPanel and FTP and the normal hosting stuff, I can provide SVN hosting!

Kshitiz_Indian added 1 Minutes and 6 Seconds later...

Also, I had one more idea. Maybe when every programmer writes some code, he could comment it with his name from the start and the beginning so we know when we read it, that who wrote the code?

SVN requires remote access to the computer. It runs as a completely separate process than the web-server (or its easiest to configure it to do that, imo). If SVN isn't installed on your server you'll have to remote in and install it. Then you can follow the SVN guide to get it running.

My server has died hopelessly, let's see when it wakes up again.

sohummisra added 5 Minutes and 37 Seconds later...

I have been working on a cricket simulator for the last few months. By far the hardest part is getting the simulator to spit out accurate results for each ball. I think that putting off the engine design is a mistake because it will take the longest to get right. It's better to do the engine design iteratively. Decide on what player characteristics to model (my program only uses batting skill (average balls per innings), batting strike rate (runs/100 balls), bowling skill (average balls per wicket) and bowling economy rate (runs/100 balls). Then I use these to get some probability distribution of the possible ball outcomes. My results are already pretty realistic, but I don't consider things like pitch and fatigue yet. The cycle to use is

write statistical tracking module
implement engine
test
tweak engine parameters (preferably without having to recompile) and/or improve engine algorithms
repeat

That is essentially what we are doing. Backend, UI and FixturesEngine have almost no relevance to the engine whatsoever, so those parts can be developed somewhat independently. Designing of the engine is something that I think should be discussed while we have a somewhat working form of the surrounding structure.

Cliff Notes: I want to help with programming stuff

Welcome aboard! Although I don't know where you just came because the project is in a bit of disarray with source code control/sharing essentially off at the moment. I'll see if I can get that up and running at some point in the near future.

For now, do you have any experience with NHibernate or some other .NET object-relational mapping tool? If not I may go ahead and port my PHP code for Cricket Career to here, since I don't think anyone has the time or desire to figure out how that works.

 

[Kshitiz_Indian]

Sohum, I just had an idea. If we're going in for fully modularized programming, why don't we divide the teams into class libraries? Meaning each team would have a class library project except maybe the UI and the core sim which will be together, and the references of the DLL's of the fixture engine, the backend and the statisticsengine can be added. This will have 2 advantages.

1. Each team can follow either C# or vb.net.
2. When we want to change something related to, say a fix in the fixture engine, we'll only have to replace the DLL file incase of a minor change, rather than releasing the whole simulator exe again.

How about it?

 

[Isura]

Sohum,

No I'm not familiar with those mapping tools. Have you considered a purely object oriented database ? That would eliminate (most) of the mapping issue, but it will introduce some speed issues and learning curve compared to SQL systems.

 

[sohum]

Sohum, I just had an idea. If we're going in for fully modularized programming, why don't we divide the teams into class libraries? Meaning each team would have a class library project except maybe the UI and the core sim which will be together, and the references of the DLL's of the fixture engine, the backend and the statisticsengine can be added. This will have 2 advantages.

1. Each team can follow either C# or vb.net.
2. When we want to change something related to, say a fix in the fixture engine, we'll only have to replace the DLL file incase of a minor change, rather than releasing the whole simulator exe again.

How about it?

Sure, but for the references to work we need to get our interfaces up asap. I am going to start coding next weekend. I'm moving back to Rice this weekend so I should have a desk (finally!).

sohummisra added 2 Minutes and 4 Seconds later...

Sohum,

No I'm not familiar with those mapping tools. Have you considered a purely object oriented database ? That would eliminate (most) of the mapping issue, but it will introduce some speed issues and learning curve compared to SQL systems.

I have thought about it but I think it would be overkill for this project. Especially if we are planning to allow a local version (no internet connection) that would use a SQLite DB to be used to store data. We don't want users to have to install a ODBMS just to run the simulator.

 

[Kshitiz_Indian]

Sure, but for the references to work we need to get our interfaces up asap. I am going to start coding next weekend. I'm moving back to Rice this weekend so I should have a desk (finally!).

Ok then, but we'll need 3 different projects alltogether for the 3 class libraries. I'm guessing, if the server doesn't come up very soon, we could go in with sourceforge?

 

[sohum]

The new server has been purchased. Set-up is now in progress.

 

[Kshitiz_Indian]

Great news! Thanks for all the efforts sohum.

 

[sohum]

Looks like my new host (not a virtual server) can only provide SSH access through SVN. So I will be setting up SSH accounts for all of you soon. I'll let you know when they're ready and also further instructions for connecting and such.

 

[sohum]

I have set up the new repository. Please PM your choice of username and password again as I deleted those messages. I will then PM all of you the instructions to log-in and such.

sohummisra added 55 Minutes and 42 Seconds later...

I am going to be creating the new solution in Visual Studio 2008. This means that each sub-project can be in a different language. Here is the break up as I understand it now. Please let me know if it is different:

Backend - C#
FixturesEngine - C#
StatisticsEngine = VB
SimulationEngine - C#
UI - VB

 

[Kshitiz_Indian]

It seems just perfect. Let us know how is this going to be implemented since we don't all have visual studio 2008.