| Part I Mostly you don't need and don't want a 'technical co-founder'. Also, the concept of 'a developer' without being a lot more specific makes little sense. Here's the situation: (A) You can go to college and study stuff and learn, say, (1) getting good at reading for comprehension and writing clearly, (2) the precision, discipline, and tools in pure math, (3) some topics in 'computer science', and (4) thinking 'critically', that is, accurately putting candidate ideas into the correct one of the three buckets True, False, and Not Clear Yet. (B) You can learn how to do the programming you need for your project. (A) can help with both (B) and your project, but it's likely quite possible to do both (B) and your project without (A). For (B), what you need to know about 'development' is what you need for your project. Here is a fact of life in Computer-World: The world is like a hardware store the size of Texas and packed floor to ceiling with tools. There are LOT of tools. Each tool takes time and effort to learn to use; the main problem is that the tool builders are just awful at describing their work; if you have the usual advantage in verbal skills over male computer nerds, then the documentation may cause you to yell and scream in outrage and agony. The best technical writer is God, usually better than the pure mathematician P. Halmos. Way down on Earth is D. Knuth. All the rest in computing are in the infernal reaches. But, for anything very complicated you might need to do, there is likely a good tool for it, and it will nearly always be easier to learn to use the tool than to do without or build your own. So, most of what you need to do to be the 'developer' you need is just to learn to use some good versions of the tools you need. Yes, now largely the software you need to write is just a little 'glue' joining together the 'blocks' that are the tools you use. Can a 'developer' learn all the tools in that big collection the size of Texas? Not a chance! Heck, even being a 'librarian' just cataloging the tools would be more than a full-time job. Further, the collection of tools keeps growing, quickly. So, here's a deep, dark secret ALL, REAL MALE HACKER nerds keep to themselves (and never but NEVER tell women!): At the start of each new project, it is necessary to learn at least some new tools. So, really, NO developer is ready to 'develop' without learning some new tools. So, one of the main differences between you and any 'developer' is that you just have more tools to learn. Next, you will need some basics: So, you will need a PC, at least reasonably current. I built mine from parts five years ago, and it's still fine. You need to get good enough to send and receive e-mail and to use a Web browser. Since you are already posting on Hacker News, apparently you've got this part done. If you don't know Computer Parts 101, then have someone give you a 30 minute lecture. The final exam will be to go to Tom's Hardware Page and Tiger Direct and explain what you are seeing. For a Web site business (common now), you need to know Internet and Web 101. Again have someone give you a 30 minute lecture. Next you need to get started writing software. Here you should pick between the world of Linux and the world of Windows. While Linux is likely more popular on HN, I recommend Windows if only because there is a company behind it with some tens of thousands of programmers, is a CEO who commonly yells and screams, is a COB who remains one of the sharpest tacks in the box, is about $40 billion in cash in the bank, are some very serious enterprise customers that mostly are pleased, is a LOT of free software (really, after you buy a copy of Windows, darned near all the rest of their software is available for free in 'Express' editions -- yes, where you spend your time and effort learning their software so that you can use it in production and then pay the big bucks), they work HARD on documentation (they should work much harder), and there are so many people programming Windows that for nearly any problem you encounter many others have been there before you, and a Google search can turn up a forum with answers. One of the best things in computing is Microsoft's .NET Framework. So it is a collection of relatively low level software tools, maybe the size of half of Texas, to do nearly anything more than two people have ever needed to do. .NET is enormous. Next, heavily your 'development' is to exploit .NET, and for that you have mostly just two good alternatives, use the language C# or use (the more recent version of) the language Visual Basic. I strongly prefer Visual Basic because it is much easier to read on the page and lets you do very nearly as much as C#. For C and C++ -- f'get about them on Windows now. Part of .NET is ASP.NET where ASP abbreviates 'active server pages'. They aren't very 'active'. Really ASP.NET is just a way to write software where you mostly don't have to work much with lower level things like HTML and JaveScript. For nearly anything standard in Web site development, ASP.NET has tools to make the work easy. E.g., for a lot of what is needed, it's necessary to write JavaScript code, but ASP.NET does that for you. Nice. You may be able to make a lot of use of JavaScript without ever seeing it. There is also ADO.NET where ADO abbreviates 'active data objects'. They can be somewhat 'active', but I mostly avoid depending on that. ADO.NET is how in a program you manipulate the database system SQL Server or one of its competitors, Oracle, DB2, etc. SQL abbreviates 'Structured Query Language' which is closely associated with database. What is 'database'? Since the work on 'relational database' at IBM and U. Berkeley in the 1970s, mostly we store important data in a relational database. Microsoft's version is SQL Server. A database remains conceptually like some stacks of paper forms say, from the IRS. So a 'database' consists of some 'tables'. Each 'table' consists of rows and columns. In one table, all the data is for just one IRS form, say, Form 1040. Each row is like one copy of an IRS form, that is, has the data from just one copy of the form. Each column is like one of the 'fields' on the IRS form for that table. You can designate a column as a 'key' which is like an 'index' which means that, given a value of the key, the software can read the row with that key value quickly. In the case of IRS Form 1040, one column may be SSN; you may designate it as a key; and then you can regard the database as a stack of Form 1040 copies sorted in order on SSN. Simple enough. A table can have at most one 'clustered key' in which case the rows are stored on disk in essentially key order, and that can make some operations faster. Whatever you may do with relational database for a Web site, if your business gets significant, then almost certainly you will store all your routine business records in relational database. The main idea in database 'design' is for the keys and the other columns to be in 'third normal form' which means that each row is conceptually, in the problem being solved, 'a function of the key, the whole key, and nothing but the key' -- think about this a little and you will see why. Part of the glory of relational database is 'transactions'. The key here is the 'log file': For each 'transaction', which is just some sequence of database operations that you say are all part of some one 'transaction', the operations are written 'provisionally' to the log file and to the database itself. At the end of the work of your transaction, there is one more 'atomic' write to the log file saying that the transaction is done -- 'committed'. So if the computer goes down, when it comes back up the data base software first reads the log file and 'undoes', 'rolls back', all the transactions that were in progress but not 'committed', The classic example is moving money from checking to savings: If the bank's computer quits, then once the computer is running again, the money has either been moved or has not been; there is no case of the money being lost 'during moving'. Another part of transactions is 'integrity': So there can be many programs running at the same time manipulating the same database. E.g., while you are moving money from savings to checking, the bank can be updating your checking account, and nothing gets confused. To make this work, relational database has to work with 'locks' and 'deadlock' detection and resolution. The simple case is two programs, A and B, that both need to manipulate data X and Y in some careful way. So, program A gets a 'lock' on data X; program B gets a lock on data Y; program A then waits until it can get a lock on data Y; program B waits until it can get a lock on data X; and now programs A and B are in a 'deadlock' since neither can complete and will wait forever. Relational database detects such deadlocks and resolves them. E.g., program A may have its work on data X 'rolled back' and its lock released; program B is allowed to run and finish, and then the work of program A is just restarted. Nice. In particular, yes, it is standard to backup a relational database while it is running. Mostly manipulations of relational database are done with the language 'transact SQL' (T-SQL). So, even if you are using ADO.NET, what goes to SQL Server is T-SQL. You can run T-SQL statements just by typing them into a file and giving it to the SQL Server program sqlcmd.exe -- I like doing that. For SQL Server, there is a level lower (closer to SQL Server) called 'Server Management Objects' (SMO) you can use in, say, Visual Basic. You now know Database 101. |
Yes, since we mentioned that database and printed forms are close, sure, database and forms on a screen, from either Windows or a Web page, are also close, and there is software to make routine 'forms' applications easy.
All things considered, as serious programming languages go, Visual Basic (now) is close to the top of the list both in what it can do and how easy it is to do it. Its 'managed memory' is nicely advanced and a real help for programmers; there's hardly a programmer on the planet both smart and careful enough to write significant on-line software without the help of 'managed memory' and not make at least some fairly serious errors.
What do you type into? Mostly the norms are to type your software into an 'integrated development environment' (IDE), and on Windows that would likely be Visual Studio (VS). For the Microsoft relational data base software SQL Server, are supposed to type into SQL Server Management Studio (SSMS).
I minimize SSMS and flatly refuse to use VS. Instead I just picked a good text editor (KEdit) with a lot of power (including an elegant macro language to automate things) and use it to type this post, TeX for mathematical word processing, e-mail, Visual Basic code, SQL Server 'scripts' in the language T-SQL, Web pages (using ASP.NET), and more.
Then I also have a 'scripting' language, ObjectRexx, also elegant. Likely now a better alternative would be Power Shell.
Then get a copy of
Jim Buyens, 'Web Database Development, Step by Step: .NET Edition', ISBN 0-7356-1637-X, Microsoft Press, Redmond, Washington, 2002.
It is some of the best technical writing on computing ever typed in.
That book will very much get you going.
For more, just look at the other books in the Microsoft series, read the on-line Microsoft documentation, and find more via Google.
No source of information on current programming is without flaws: For each topic, it is usually good to have more than one source. If from one source something is just not clear, then don't blame yourself and, instead, try other sources.
In the code you write, here's the most important consideration: Put in a lot of comments explaining what you are doing, and also put in references to the documentation on the details. Write your documentation clearly enough that anyone else could read your software and understand it, and that includes you six months from now. Otherwise, when you write your code, only God and you will understand it, and six months later, only God. This is why if you ask a 'developer' to modify a program written by someone else, the developer may just start over.
For 'quality', put the software aside until you forget the details, and then 'proof read' it as if some person you hate wrote it and you will get $1000 and bragging rights for each error you find.
Another point is, at any point in your code, when you receive data, CHECK it for reasonableness. So if you are writing some code to scan a list of users and find those in Maryland, make sure the code works even if the list has only 1 entry, no entries, no one in Maryland, and everyone in Maryland; this is called testing 'edge' cases. The easiest place to find subtle errors is in the edge cases. The easiest way to check correctness in edge cases is just to read the code carefully, VERY carefully, one edge case at a time.
In particular, if your Web site takes in data from a user, write code so that just absolutely, positively nothing at all can ever go wrong with your code no matter WHAT bits or bytes come in from the user -- no matter WHAT.
If you hire anyone, then they will have to do maybe 30% as much as you will in learning. Or, they learned HTML and then had to learn CSS, then ADO.NET, then Ajax, then Flash, then HTML5, and now four different smart phones. NO ONE knows all such stuff and, instead, just has to learn. The main difference for you is just that initially you have to learn more.
If you don't have (A) above, especially for computer science, then will this be important? Likely not: Occasionally you may do something inefficiently. For questions, post on fora, including HN. Again, mostly you will just be writing glue, not blocks that the glue joins.