// Setup
int n = 2;
int[] m = { 3, 5, 7, 1, 8, 4, 2 };
int[] smallest = (int[])Array.CreateInstance(typeof(int), n);
// My answer
Array.Sort(m); Array.ConstrainedCopy(m, 0, smallest, 0, n);
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
Or... Assuming the string has only military time with no date:
string strReturn = DateTime.Parse(DateTime.MinValue.ToString("MM/dd/yyyy ") + strTime).ToString("tt");
If it has date and time:
string strReturn = DateTime.Parse(strTime).ToString("tt");
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
By the tone of the question, I'm assuming that the senior dev has asked you to throw together something quick and dirty to get a specific job done. Under the right conditions, that may be ok. If it is a run-once tool to correct/convert something in persistant storage (example - you have been storing some text data, say xml, in a VARCHAR(MAX) column of a table in the database and need to start compressing the data and storing the compressed byte array in a new IMAGE column to save drive space. Converting the existing entries would be a good job for a one-off run-once tool). It's ok to write something like this without adhearing to all of the "best practices" as long as it runs once and gets the job done correctly. Data import from a legacy application to a new one is another example. However, if it is something that is to be a part of the system, even for a short while, you are right to want to make it as stable and maintainable as is allowed under whatever time constraints you have. That being said, I don't know the office politics climate where you work. If your senior developer is a real tyrant and has the ear of management, there is no need to argue or stress over it, just do it and move on. If he is open to ideas and suggestions, voice your concerns, and once you have, follow whatever decision he comes up with. The reality is that, in the end, you are there to do a job. I recognize and applaud your passion for doing it right, but until you are the one in the position to make those decisions, I'm afraid you're going to be stuck doing as you're told (sometimes called "paying your dues"). As distasteful as it may sometimes seem, you don't need to let that passion die, but you may need to occasionally rein it in a bit, and get the job done.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
Absolutely true, there is no perfect random number generator. I was just showing an example of using the Windows Guid generator (pretty darn random) to seed the RNG. Really it's kind of a moot point, in that, according to MSDN the RNG seed value is ignored in the present implementation. It uses some undisclosed seeding method internal to the constructor.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
How about... public static Int32 random(Int32 lowerBound, Int32 upperBound) { Int32 range = (upperBound++) - lowerBound; byte[] seed = Guid.NewGuid().ToByteArray(); RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(seed); byte[] sequence = new byte[1]; rng.GetBytes(sequence); return (Int32)(sequence[0] % range) + lowerBound; }
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
Observation, in and of itself, does not alter the state of the cat, it mearly changes the observer's perception of the state of the cat. Which confirm's the inadequacy of the thought experiment as it relates to quantum states, where observation does in fact alter the state of the observed.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
It's not the language - it's the caliber of developer. I've seen some C# and C++ projects that would rival if not surpass the code you've described for it's shameless depths of bad practices/code/formatting/architecture/etc. I've also seen some very good work done in VB (not to try to say that I haven't seen some comparably bad VB - but I haven't noticed an inordinate disparity in the amount of bad code I encounter as related to the programming language).
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
On the free side I use NotePad++, for a paid editor, I like UltraEdit.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
In addition to many of the tools mentioned in the other responces I ues Frhed (Free Hex Editor) to view the contents of binary files. And WinMerge as a stand alone text file comparison tool. Both are "Freeware".
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
Current best practice is to use parameterized queries. This is what most ORMs do under the hood. If you only allow SPs, you have to hand constructed SQL to your ORM, which negates the reason for using an ORM in the first place. If you are not using an ORM, then I would agree that the safest thing to do is to only allow SPs at the DB level, but it is not the only solution. If you have decent developers, parameterized queries is still the way to go. Limiting DB access to SPs is not necessarily best practice, but does help protect you from developers that don't know what they are doing (best thing is probably not to hire those guys in the first place).
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
Of course this is just my opinion, and by no means definitive. But as I see it, at the basest level, the language is the instruction set of the computer's processor. Without being organized into patterns that represent processor recognized op-codes and operands (language), binary is, in and of itself, meaningless. Just as a string of alphabetic characters is inherantly meaningless until organized into recognized words and phrases to give it meaning (the rules governing that organization to convey meaning being language). The difference between an alphabet and a language comes in the organization. Alphabetic (as well as binary) characters are the building blocks of language, but not the language itself, it is the rules that govern organization of binary representations into meaningful patterns of action and data that constitute language. For a computer, that organization is the perscribed behaviors of the instruction set's op-codes on data operands that constitute language.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
I know this isn't exactly what you asked, but make sure you don't overreach. It is better to hand in a finished mediochre program, than an unfinished grand program. The semester at most schools is about 15 weeks (shorter if it's a summer semester), make sure you can finish your program in the time allotted. I know that sounds like a lot of time, but it isn't, especially when you condsider that you will have to attend classes, do homework, study for tests, have a bit of a social life, and complete this project. 1. Take some time upfront to define, in detail, the problem you are trying to solve (this is the basis of a good design) 2. Come up with a design that solves the problem. Don't worry about having a clever twist, just solve the problem (in the course of this a clever twist may present itself, but don't worry if it doesn't). 3. Implement your design. 4. If time allows - go back and refactor. Unless you write pristine code off the top of your head (been in the industry over 15 years and haven't met anyone yet that does) this will improve readability, reliability, and often performance. 5. Provide consise, understandable, accurate documentation. Now on to the project suggestion (this part will probably get ignored - my suggestion is not particularly sexy and dosen't have any wiz-bang) Probably the easiest thing to do (maybe not sexy but useful) is to write an accounting program geared to a specific small business that does not traditionally have or use one, but could definately benefit from one e.g. Mom & Pop grocery store, small auto repair garage, mall bodega, bar/club, hair salon - you get the idea. This has the double advantage of possibly becoming something of commercial interest down the road. Most small independant businesses, would love to use a computer to their advantage, but simply can't afford the required software or training time, a cheap program that provides: Accounts Receivable Accounts Payable Inventory Payroll Point of Sale Booking/Scheduling specific to a given business should be a viable/worthwhile project. You may even be able to find a small business that will let you come in and observe how their business is run for a few days. This could make your design a slam dunk. A quote for you - "Make it work, then make it elegant, then make it fast." - from "The Fishbowl" blog of Charles Miller
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form tha
While not incorrect by any means, IoC/DI can be as simple as:
/*
* Simple Inversion of Control/Dependency Injection
*/
using System;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Text;
using System.Configuration;
using USCG_SSO.Interfaces;
namespace USCG_SSO
{
public class ObjectFactory : IObjectFactory
{
public ObjectFactory() { }
// Create an instance of an object
public T getInstance()
{
return getInstance(null);
}
// Overload create instance of an object using creation parameters
public T getInstance(object\[\] initializationParameters)
{
NameValueCollection appSettings = ConfigurationManager.AppSettings;
Type type = Activator.CreateInstance(typeof(T), initializationParameters).GetType();
// Any special initialization for an object should be placed in a case statement
// using that object's fully qualified type name
if (initializationParameters == null)
{
switch (type.ToString())
{
case "USCG\_SSO.ServiceUser":
NameValueCollection appSettings = ConfigurationManager.AppSettings;
initializationParameters = new object\[\]
{
appSettings\["ADUserID"\],
appSettings\["ADUserPassword"\],
appSettings\["ADFieldName"\]
}
break;
case "USCG\_SSO.ActiveDirectory"
initializationParameters = new object\[\]
{
new ObjectFactory().getInstance(),
new ObjectFactory().getInstance()
}
break;
default:
break;
}
}
return (T)Activator.CreateInstance(typeof(T), initializationParameters);
}
}
}
Assuming: USCG_SSO.ActiveDirectory object requires a ServiceUser object and a CurrentUser object to be passed in it's constructor, and USCG_SSO.ServiceUser object requires values retreived from the .config file in it's constructor. If you call
IActiveDirectory ADObject = new ObjectFactory().getInstance();
You would obtain an ActiveDirectory object complete with all of it's dependencies. Now, granted, this isn't as "fancy" or extensible as an actual IoC framework (there's no registration of dependencies, auto-resolution, etc.), it is, however, a complete, very simple IoC/DI implementation.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.R
How about Firebird?
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
I was a VB dev when 90% of the MSDN examples were in C++ (I translated the ones I needed to VB). Then .NET came along and MSDN did a paradigm shift and 90% of the MSDN examples were suddenly in C# (I translated the ones I needed to VB). Nowadays things are better for the VB guys, nearly all MSDN examples are in VB, C#, and C++. Just over a year ago I became a C# dev. I had learned it mostly through converting C# MSDN examples to VB (which I was working in at the time), and the new project I had been transferred to was in C#. The shift was, for me, pretty natural and comfortable. The syntax differences between VB and C# are relatively minimal. I do personally like the succinctness of the C# syntax (VB has a pretty verbose syntax). But what you need to realize from the perspective of a programming nOOb is that BASIC (Beginner's All-purpose Symbolic Instruction Code) was specifically designed (at Dartmouth College in 1964 - which makes it 7 years older than C) from the ground up as a tool for teaching the principles of computer programming to non-science/non-mathematics students (hence its verbose syntax). Remember that Microsoft's very first product, before Windows and MS-DOS, was BASIC. That being said, C++ was Microsoft's darling for years (following Pascal which they used to write the first versions of Windows - hence the pascal parameter passing convention which still survives in Windows APIs), when C# came along it became the new darling, and VB has been the red-headed stepchild. Early versions of VB in .NET were not quite as capable as C#. There were things (not many, but some) that you could do in C# that were significantly more difficult, if not impossible in VB. The early C# compiler even created more efficient MISL code than the VB compiler. Since Visual Studio 2005 all of that has changed. There is currently nothing that can be done in C# that can't also be done in VB, the compilers produce equivalent MISL, VB has finally become a full fledged member of the Microsoft development family (again). Although, at this point, I personally prefer C#, I believe that from the perspective of someone making their first foray into programming, you would be hard pressed to find a more suitable language than VB. Due to its verbose nature it is relatively easy to learn, it is currently as powerful as C#, and once the basics of good programming and principles of good design are learned, the transition to other languages (especially .NET ones) is relatively trivial.
Kevin Rucker, Applic
Been there - I feel your pain. That does not, however mean that OOP is necessarily a bad practice. There are, however two OOP principles that seem to go by the wayside in a lot of projects that tackle many of the inherent problems. They came from the DDE/COM eras (perhaps even earlier): 1. Imutability of Interfaces - Once an object interface is published, it should remain immutable, that is to say if I write an object (a) and you use it in your code, if I need to add functionality to that object I can't just change the methods already published in the interface - that would break your code. I can do either of two things, I can add new methods to the interface (leaving the existing ones alone), or create a new object (b) that aggregates the old one (a) and extends its functionality. This approach allows older code to continue to function as it always has and provides new functionality for newer code to utilize. 2. Documentation - If there is a place for developers to look to see if the functionality they need for their code already exists, it helps prevent re-inventing the wheel, so to speak, every time someone new is writing code. In addition, in order for this be be truely useful, the developers must cultivate a culture of updating the documentation anytime truely new functionality (objects) are added to the system. This does not refer to user documentation, but rather to developement documentation. Application Layering: In the days of n-tier architecture, layering was a means of reducing a seemingly insurmountably large problem into several smaller more manageable pieces. It made sense - and still does. However, for it to truely solve the complexity problem the layering has to have some thought behind it. The guiding principle here should be separation of concerns. UI, Business Processing, and Data are the major concerns addressed in most systems. Anything beyond that is usually overkill on the layers (most everything, with a little thought will fit nicely into one of the three). UI and Processing can be in the same layer, but it usually makes sense, in a large scale enterprise application, from a extensibility/maintainability perspective to keep them separate. Most modern development frameworks/patterns (Microsoft's MVC, Spring.NET, etc.) operate using this principle.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
Part 1 is a good beginning. For Part 2 check out Rob Miles CSharp Yellow Book - a free PDF - Good coverage of the basics of programming in C#. You might also check out another free PDF book by Charles Perzold - DotNetBookZero. Very good, comprehensive coverage of C# programming, but it's a bit more advanced (geared towards C and C++ developers making the move to C#). If you pull from both, you should have all of the material you need to do a beginning and intermediate course in C# programming. Intro to SQL seems fine for Part 3. Part 4 - I believe I would make the Threading and Reflection intro level and save the advanced specifics for Part 5. Threading in particular is very difficult (even for advanced programmers) to do well. Keep everything in part 4 at the intro level. All you want to do here is give a basic understanding of all the options available. I would also consider adding intros for SDLC (Software Development life Cycle) and TDD (Test Driven Development). Part 5 - These should be individual advanced courses delving into all of the things you have an intro to in Part 4. You might also want to have available advanced courses in Software Design and "Best Practices". I would not have the student(s) work on anything I intend to use in a production environment until they are well into the courses for Part 5. Until then they will have no (or at best little) concept of good software design or programming best practices. At the very advanced level, you might want to make available cources in ORM (Object Relational Mappers, NHibernate and FluentNHibernate come to mind as a very mature ones), Object Databases - Perhaps Versant's db40, and frameworks such as the Spring.NET Framework and Microsoft's MVC Framework.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
The computer is to Computer Science as the telescope is to Astronomy. The computer is just the tool that allows you to realize the concepts of CS in a concrete manner. Which is why most businesses don't refer to what we do as Computer Science, but as Information Technology. The problems are nearly always challenging, no two days (or problems) are exactly alike, and the pay is usually very good. What's not to like.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
A few thoughts: First - The part you would want to build into the CPU would be the CLR - it's the part that interprets the MSIL code (same job as the bytecode interpreter in Java), creates the proper assembly level code for the machine to run and kicks it off. Second - Make the JIT compiler and framework dlls ROM based. Everything in .NET runs compiled to MSIL, including ASP.NET, the JIT is responsible for detecting that an ASP.NET file has changed since it was last run and recompiling it to MSIL. This is what gives you the capability of changing an ASP.NET page on the fly and having the newly saved version run next time the page is hit. Third - Same problem as someone else mentioned, you would be stuck using whatever version of the .NET Framework that was designed to use CLR that you have in the CPU and the JIT compiler and framework dlls in your ROM. The only way to upgrade your Framework version would be to upgrade your CPU and ROM chips. This also means that you would be prohibited from running any third party software that requires a different version of the .NET Framework. Requiring previous framework versions shouldn't be a problem as long as you stick to 2.0+, but anything that requires a newer version will not work. But then this is generally why they don't design the hardware to the OS, but the OS to the hardware. Well designed hardware should be capable of supporting more than 1 OS.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower
Have your DBA make a test copy of the production database on another server. Do your test import to the new test database. This database can then be deleted after testing.
Kevin Rucker, Application Programmer QSS Group, Inc. United States Coast Guard OSC Kevin.D.Rucker@uscg.mil "Programming is an art form that fights back." -- Chad Hower