|
Im looking for documents(programming languages) that would guide me in creating an interface that reads network data. So i guess i should start by creating the interface or finding out how to read network data and input database.
|
|
|
|
|
What???
CodingYoshi
Artificial Intelligence is no match for Human Stupidity.
|
|
|
|
|
trying to use System.Net.NetworkInformation in the .netframe work to read network traffic
|
|
|
|
|
Tag: BeijingIT & WebFull Time
reply to: leowang@renbenmg.com Tel: 86-20-38109789
Job description:
GENERAL SUMMARY
As a senior member of the Celerra File System and Data Protection development team in NAS Engineering, you will work on complex design problems and provide highly innovative solutions.
Desirable core technical skills include file systems, distributed file systems, clustering, operating systems, and network protocols.
Strong communication skills are required for interaction with team members, senior members of the staff and other organizations. Candidate must have a broad knowledge of Linux and/or UNIX operating system technology and experience with contemporary software engineering principles. The ideal candidate will also have the ability to provide technical leadership to teams of software engineers.
Ideal candidate will enjoy a fast paced, technically challenging environment working with an expert on the core subsystems of NAS products.
Experience and Education
• BS, MS, or PhD in Computer Science or closely related field, plus at least 10, 8, or 6 years relevant experience, depending on degree
• Strong UNIX and/or Linux operating system knowledge base
o Windows knowledge a plus
• Excellent C and/or C++ programming skills
• Have multi-threaded programming experience
• Strong problem solving skills
• Expert knowledge of network and/or disk-based file systems
o Knowledge of additional storage protocols, I/O subsystems, and/or device drivers a plus
o Knowledge of distributed and/or cluster files systems a plus
• Candidate should possess excellent spoken and written communications skills.
• Ability to effectively work with and lead a team and to influence others
o Comfortable working in a highly distributed international team
|
|
|
|
|
There is a jobs board here on Code Project. Please use this instead, as I and others will be voting to remove this message.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: as I and others will be voting to remove this message
Awww damn, looks like I was too late to vote on it 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Welcome back Paul - I haven't seen you around for a while.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Thanks, man. Have been busy and now found some time to come around here again 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
You present yourself and your company as "too damn cheap to buy an ad". This kind of PR is bad branding and damaging to the image of your company 
Could they afford one?
|
|
|
|
|
Does the following C# code belong to a design pattern? If so, which one?
public class Fee
{
private Bar<Baz>.Getter myBaz = Bar<Baz>.GetAGetter();
public void Fi()
{
myBaz().DoStuff();
}
public void Fo()
{
myBaz().DoStuff();
}
}
public class Bar<T>
where T : new()
{
public delegate T Getter();
public static Getter GetAGetter()
{
T requestedItem = default(T);
return () =>
{
if (requestedItem == null)
{
requestedItem = new T();
}
return requestedItem;
};
}
}
public class Baz
{
public Baz()
{
}
public void DoStuff()
{
}
}
Bar returns a closure with an upvalue of type T. In this example, Fee's myBaz method will always return the same Baz object, and it won't be instantiated until the call to myBaz().DoStuff() during either the Fee.Fi() or Fee.Fo() method, whichever is called first.
So basically Bar provides lazy initialization of a Baz (in this case) to Fee (and presumably other classes). Do we have a name for this?
If this question has already been asked in this forum, please point me to the message.
|
|
|
|
|
At a quick glance, seems like a Singleton but a Generic Singleton Pattern. May I ask why it is important to know whether the pattern exists or not? Patterns come with time when they have proven to be successful solutions. What unique problem does your pattern above solve or why do you need such a pattern? Is it making things easier or harder?
CodingYoshi
Artificial Intelligence is no match for Human Stupidity.
|
|
|
|
|
I'm mostly curious. I'm wondering if such a pattern, or something similar (or better or more fully thought out) has emerged already in the community.
I know this code doesn't match a GOF pattern, and that it looks like a not-very-good singleton. You might call it a singleton for the calling scope of Bar.GetAGetter(). There's nothing to prevent two scopes from getting separate values though. Indeed, a single scope can get two separate values simply by calling Bar.GetAGetter() twice - each call returns a method that returns a distinct value. This is by design - it's not supposed to be a singleton.
Like I said, I think the value of Bar is that it encapsulates lazy instanciation. Since lazy instanciation is very common, and it takes 3-5 lines of code every time, and this replaces it with 1 line of code, encapsulating it seems like a good idea for all the usual code reuse reasons.
|
|
|
|
|
I'm looking for some feedback on the best/alternate ways to handle the following scenario:
Widget (defines the pool from which to create widgets)
========
Id
UserControlPath
DefaultWidget (provides a set of default properties for a widget instance)
==========
Id
WidgetId
Name
UserWidget (defines a widget with properties customized by the user)
===========
Id
WidgetId
DefaultWidgetId
Name
Given the 3 database tables above, how would you create a DTO object? I could have a class per table, but then I have to do additional queries or work with additional objects for all the data I need. I could use nested object (UserWidget has Widget.UserControlPath property). I could flatten out the UserWidget to have those properties plus a UserControlPath property.
When loading a UserWidget, I cannot display it without the UserControlPath value.
When saving updates to the properties of a UserWidget, the UserControlPath is read only - but WCF data contracts do not support the idea of read-only properties(As far as I know). Saving full object graphs can quickly become complex.
How do you model similar relationships?
Thx.
|
|
|
|
|
Leftyfarrell wrote:
I could have a class per table
I think this is a bad idea. Your tables are designed so data is normalized. Your code--classes--should be designed to normalize behavior not data. Think of your problem domain, jot down all things you need to do to these objects, assign these things to appropriate classes. Try to normalize behavior by using inheritance.
That is all I can say because I don't know too much about what you are trying to do.
CodingYoshi
Artificial Intelligence is no match for Human Stupidity.
|
|
|
|
|
Thanks for your reply.
I agree that I don't like the class per table idea. Tables are normalized. Classes should represent proper domain objects.
The question then becomes, where do you draw the line on CRUD operations. To me, a UserWidget without the UserControlPath property is kind of useless. On the other hand, when you save a new UserWidget, you cannot edit/change the UserControlPath property value. You could consider it a lookup and allow them to change the WidgetId (indirectly choosing a different UserControlPath).
But, if the UserWidget is exposed via WCF, read-only properties are not supported. So I can expose the WidgetId, which is editable, but if I provide a string UserControlPath property, it becomes editable on a WCF data contract, which I don't want.
So they load up a UserWidget object, change the UserControlPath string value, and submit the object for saving... now what? Ignore the property value? Allow the saving of this instance to change the value for all other instances? Neither sounds very elegant.
|
|
|
|
|
Do something like the following the following--private setter:
[DataMember()]
partial public class Foo
{
public string FooBar
{
get {;}
}
{
private set { ; }
}
}
Leftyfarrell wrote:
The question then becomes, where do you draw the line on CRUD operations.
What do you mean draw the line?
CodingYoshi
Artificial Intelligence is no match for Human Stupidity.
|
|
|
|
|
Thx, will check into that.
By draw the line, I mean with nested objects in an object graph. Not really shown in my object/table example above. But for instance say you have a Course, Session, and Location. A course has multiple sessions, and each session has a location.
Does your Course object have a Collection<session> objects for reading convenience? What about CRUD on the Course, where do you "draw the line"... if you add a Session to the collection, do you now save the Course AND insert a new Session? If the Session has a Location within it, and you add a new Location to a new Session and add that to a Course and save the course, do you Insert the Session and the Location?
It seems to me that dealing with object graphs for CRUD operations can get complex quickly. But having those properties does properly represent the domain model, and certainly does improve the way you work with the data when only reading it (loading Course, Session and Location info for display purposes). Then for performance reasons, you might get into lazy loading, although that may not be feasible either across WCF boundaries.
It seems all about the trade-offs and I'm just looking for the right balance that makes sense.
|
|
|
|
|
Okay I know what you mean.
It all depends on the requirements. For example, let's say you are managing customers, their orders, and lineitems. Now the questions to ask are:
1. Within my problem domain, do I want to create LineItems or do I only select from LineItems and add to order? If you only select then LineItem will not have any CRUD operations except Retrieval.
2. What about Customers? Will I be adding new customers who have absolutely no orders into the system? Chances are yes, therefore, therefore their might be times you want to load a customer to edit their information. It does not make sense when you call Retrieve (R from CRUD) on customer to also load their orders, and all the line items for the order if all you need to do is change the customer's name from Bob to Rob. But if within your domain you never do any CRUD operations except Retrieve on customers (customers are added using some other app), and the only time you retrieve them is to load their orders then it make sense to retrieve all orders and lineitems when a customer is loaded.
Where to draw the line? You choose by looking at the problem at hand.
CodingYoshi
Artificial Intelligence is no match for Human Stupidity.
|
|
|
|
|
That is a good analysis of some sample requirements. The next complexity that comes to mind is definition of the entities to support both scenarios.
Admin area allows you create a customer. User area allows viewing the Customer, together with Orders and LineItems. I assume the same Customer entity is used for both areas of the system.
Now in the admin area when creating a customer, you simply have a Collection<order> that is null. This keeps things fairly simple. If it was not null, would you design your system to handle it (insert Orders too) or would you throw an exception and force things to remain simple for CRUD operations beyond reads?
|
|
|
|
|
A Customer should have a collection of Orders, and Orders should have a collection of LineItems. As soon as you create a customer, you know you need orders, therefore, instantiate a collection of orders. Do not leave it null but leave it empty and then orders can be added. If orders are not allowed to be added then throw exception or handle it some other way.
Leftyfarrell wrote:
you simply have a Collection that is null.
Like I said above this should be empty but not null--at least this is how I will design it. When a customer enters a store, he/she grabs a shopping cart but it is empty and then if he/she needs something she adds it. If he/she does not grab a shopping cart then what? Someone else has to grab it--I don't know about this.
CodingYoshi
Artificial Intelligence is no match for Human Stupidity.
|
|
|
|
|
Hi,
I wrote myself an Access db several years ago to do some things for my checkbook and budgeting and I've really enjoyed it ever since. Lately I've been thinking about writing it as a stand alone program so I could let my family and friends use too (I don't want it to be Access dependent because I don't want to have to troubleshoot and support it on different versions of Access or MDAC).
Anyway, I once took a class on OOP Logic and a C++ class, and as I was thinking of how to design it, I was thinking in terms of objects. For instance, a transaction would be an object with attributes like a date, amount, etc. But then I realized that designing it this way seems to be fundamentally different from the way I did it originally with Access. So it looks like the first big decision I have to make is to decide whether to use object oriented db design or relational db design. Is this true, and if yes, which way would be better to go for a checkbook/budgeting app?
Thanks for your help.
|
|
|
|
|
Here's some thoughts of the top of my head.
copec wrote: whether to use object oriented db design or relational db design
It's not an either/or decision. If you think of the app as having two parts (i.e a user front end and a data storage back end), the front end could be OOP and the back end a relational db.
The two ends have to communicate and you can do that in a number of ways, two possible approaches are:
1. Use the data binding common in MS Windows forms and IDEs such as Visual Studio. This is essentially what Access does when you build forms using the wizards.
2. Put a data access layer (DAL) between the front and back ends. Possibly Model-View-Controller pattern. Enterprise solutions ought to go down this path, but it might be overkill for a single user app.
If you don't want to use Access you have to decide how to store the data. Options include: flat files (CSV?), XML, some other database.
You need to determine what the other users have on their machines before deciding.
"Thoughts of a dry brain in a dry season" - Gerontion, T S Eliot. 
Regards
David R
---------------------------------------------------------------
"Every program eventually becomes rococo, and then rubble." - Alan Perlis
|
|
|
|
|
Thanks David.
Wow, you used a lot of words a phrases there I've never heard before.
It's good news (I think) that I can use my OO knowledge with standard RDB tables to store the data because I already have a working model in Access and I understand a little about OOP. How do I decide what language, db, gui, toolbox, etc to use keeping in mind: 1) I have a little c++ training, 2) need the most stability I can reasonably get, 3) free tools that I can sell if I decide to one day? btw, Windows only compatibility is fine, especially as I'm assuming cross-compatibility requirements would only make finding a solution more difficult.
Thanks again.
modified on Saturday, July 11, 2009 10:34 PM
|
|
|
|
|
Here are some thoughts. (Rather longer than I anticipated!)
If you have a developer edition of Office you can package your .mdb together with a run time version of the
Access engine. This would be the simplest thing to do - I believe it would take care of the MDAC issues but have never used it.
IIRC the license is that you must have the developer edition Office Pro is not valid.
The beauty of Access is that the .mdb file contains everything - user interface (GUI) and data store (i.e. db tables etc).
So the whole app can be self-contained (unless you use linked tables).
If you move from Access then the GUI and and the data store will be separate components that need to talk to each other.
So you have to decide what to use for the data store and what to use for the GUI.
Looking at the data store, main driver for this decision has to be 'What do potential users have on their machines?'
If they have Access why not stick with it? If they don't then some possible options are.
1. Use flat/text files - the traditional (antedeluvian?) way that requires a lot of coding
(having said that, I know of one major UK retailer whose warehouse management system is run using flat files.)
This approach would mean that the users would require nothing special.
However, you would have to think about securing the files so users cannot edit or delete them.
2. Use XML - this is what many would advocate. Essentially they are structured text files on steriods. But that requires learning about XML.
Similar pros and cons to flat file. But there are other benefits and lots of example code on the web.
3. Use an OOP language and the object serialization that is built in.
Not always as easy as it seems but would be self-contained.
4. Use a relational db.
There are some free ones that you could investigate e.g. SQLite, MS SQL Express.
You would need to be able to package and distribute the db with your GUI app, and that might bring problems similar to the MDAC ones with Access.
For the GUI and the ability to communicate with the data store you still have to ask 'What have the users got on their machines?'.
You also have to ask 'What am I comfortable with and how quickly can I get uo to speed?'
These days you're pretty much obliged to use an OOP language. Possible options are:
1. Java - I once heard it described as 'C++ For Dummies' so knowledge of C++ would be helpful.
It's free and cross-platform and there's some nice free IDEs (NetBeans and Eclipse are considered good).
Personally I think it started off being really good but has now added a plethora of classes that make it just too much of a hassle to do simple things.
Users will need the Java Runtime Engine - but that's free (and there's probably a version on their machines - but might need updating).
2. VB.Net - there's a free version (VB 2008 Express) that comes with the Visual Studio IDE (well a cut down version).
It's a 'true' OOP (unlike VB6 which it is related to it as Italian is to Latin).
It's easy to build apps similar to Access ones (especially if you use SQL Server Express as data store).
Requires .Net Framework 3.5. But that's freely available and re-distributable.
3. C# - similar to Java/C++ in syntax. Also a free Express version.
Same pros and cons as VB, more or less.
4. C++ - there's also a free Express version.
Never used it so cannot comment. I expect it's similar to VB/C# in what it provides.
You could also look at Mono - it's an open source implementation of .Net and available for Linux and Wondows.
Never used it but heard good things about it. Tends to lag behind MS .Net since it's always playing catch-up.
Regards
David R
---------------------------------------------------------------
"Every program eventually becomes rococo, and then rubble." - Alan Perlis
|
|
|
|
|
Thanks so much for this info. A lot of it is new but some of it fits in and clarifies other things that were foggy.
It may show that I don't really understand what I'm talking about, but, in no particular order:
--I used to support some Access apps that ran on MDAC and Access on various clients and there were always problems coming up. That's why I'm drawn to developing a truly independent program.
--I'm definitely leaning toward an RDB data store instead of an OODB, or the other choices, because I already have a working -though improvable- model of the data in RDB (my existing mdb) and it seems like the "best" way to store number data.
--From this and other info I've read I guess it's a two way tie between C++ (I had the Intro to C++ class) and Python (seems to be widely liked) for the front-end (is this right terminology?) with Java still kind of in the running (don't love that it is dependent on JVM).
--Should I not be concerned about stability or security of using something built on a platform, like JVM or .net?
--Could you talk more about this?: "You would need to be able to package and distribute the db with your GUI app, and that might bring problems similar to the MDAC ones with Access."
--I understand what the language and libraries are, but could you explain why I need toolboxes, wrappers (like wxpython)?
--Regarding IDEs, I found these at http://wiki.python.org/moin/IntegratedDevelopmentEnvironments[^]. How do I choose between "IDEs with introspection-based code completion and integrated debugger" and "IDEs with integrated gui builder"?
And thank you again. I really appreciate your help.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
