Related
I maintain in-house business software for a living. Technologies included here are Java, Struts, Spring MVC, jsp, wicket, and a few others. I think it's time to branch out and learn something new.
I am hoping to show myself with a side project that writing code can, in fact, be fun (in some plane of the universe), and that I haven't wasted the past few years of my life doing something I can never love or have fun doing.
I'm thinking of having a fantasy-sport style web site - obviously much, much smaller with regards to features and all that. I was hoping I could get some recommendations for the newest or cleanest frameworks that will allow me to accomplish such a project. My goals are to work on following a real development process instead of just hacking a bunch of crap into an already crappy application on a daily basis. Also I will strive to follow best practices and create good, clean, understandable code that I don't shudder at the thought of having to modify. It's hard to do this at work, because the software I work on has already been developed by 50 guys from various continents that never took the time to design anything before jumping into coding.
I would need a simple database to store users and their picks for each event. Also at my job, the login security is all handled by another group completely. Do people usually write their own login systems from scratch, or are there open source utilities for that as well? I'd be interested in those, as my site will need to have a user login system, and be secure.
I had ruby and rails installed on my computer the last time I conjured up the motivation for this idea, but that was nixed by a hard drive crash. I figured before I just jumped straight to rails for this idea, that I would get a few other opinions off stack overflow to see if people liked something else that I didn't know about.
Also, if anyone has any good resources for how to think about OO design, I could brush up on that as well. I'm looking for anything that will help me to just think about the design from the start and how to get my thoughts into a diagram. I'd like it not to focus so much on patterns and other principles as much as just how to get started and actually put my thoughts in a professional document that I can use to build my project from. I tried to practice this prior to a card game that I wrote, and it got way too complicated way too fast, and the results ended up being not so great.
I’m more familiar with Django, although like you, the only frameworks I’ve really used are the Java/Struts/Spring/JSP, etc. The automatically generated administration interface in Django is amazing coming from these, and it comes with its own authentication system too.
Unless you’re especially predisposed against Python, I think you should give it a go.
Ruby on Rails, Python on Django, PHP on (not sure -- maybe Zend? or CakePHP?), are probably the most popular frameworks if I understand correctly that you want to learn a new language. If I misunderstood you, and you'd rather stick with Java, GWT seems pretty cool -- it's the only real way to avoid "explicitly" writing Javascript (if you DO want to learn and use some Javascript, I personally am in love with Dojo, but jQuery is substantially more popular: those are two good popular frameworks you should consider, though there are others of course, like for all languages I mentioned so far).
One advantage of picking Python and Django is that they work particularly well with Google App Engine (and with Dojo, too, thanks to the cool dojango project!) -- GAE supports JVM too, now, but it's supported Python for a much longer time and the Python side of it is more solid and complete at this time. So, if that's the technology stack you choose, you get to develop and deploy for free, on highly scalable infrastructure, at least until your app gets more than a few million page views per month -- and you really minimize your system adminsitration hassles, all you do is basically to code and write one simple configuration file.
On another programming related website, I saw this line in someone's signature. This is NOT the first time I've seen such sentiments, although this is the harshest:
"People who work in VB or any variant
thereof are not programmers, they are
circus chimps throwing feces into an
IDE..."
VBA is my bread and butter and I can automate quite a bit of stuff with it. Yes, I know it lacks polish and some functionality, but why so much negativity toward it? On the flip side, what do other languages have that VB doesn't?
VB6, VBScript, and VBA have the reputation because they just aren't industrial strength languages. Notably:
No OOP. Sure, you have classes and modules, but no inheritance. VB isn't a low-level language, it needs real objects.
No first-class functions, so you can't even simulate OOP or polymorphism.
Lack of a well-developed class library. VB6 has a small library of built-in functions, and almost all other functionality is delegated to Windows calls or (usually pricey) third-party components.
Lousy error-handling. ON ERROR RESUME NEXT is a pox on the planet.
Although its not the fault of the language, VBA earned a bad reputation by association with MSAccess.
Of course, VB wasn't really intended to be an industrial strength language, so maybe nothing mentioned above is really proper criticism of the language at all. Fortunately VB.NET and the latest versions of VBA fix everything above, so VB.NET is on par with any other "serious" language in the marketplace.
[anecdote]
In defense of VB, I find most people criticize the language just to go along with the status quo, not because they've actually used it.
A few years ago, in a chatroom, I ran across young neophyte railing against a VB6 developer for using such a crappy language. I innocently asked "what's wrong with VB".
The first thing he said was "Because its a WINDOWS language!" So I pointed out that Borland Delphi is a Windows only language*, but I've never heard anyone malign it for that reason. (* There was a product called Kylix which cross-compiles to Linux, but its expensive, buggy, and discontinued. Its been a while since I've used Delphi, but last I'd heard, its still not ready for Linux.)
So, he said "It has a HORRIBLE SYNTAX!" Is that really the reason people hate this language? I'd say Perl, Lisp, and C++ are worse on the eyes than VB.
Next, he says "Its too easy to learn!" Well, I'd consider that a point in favor of the language. I'll never write a GUI by hand if I have a drag-and-drop designer at my disposal. What else you got?
So finally, grasping at straws, he comments "It has... no string manipulation functions". Left, Right, Mid, Replace, InStr and Trim. QED noob.
Interestingly, VB has features found some "hacker" languages, namely variant datatypes and duck typing. Compiled code performed reasonably well, interop between COM and native windows DLLs was easy, and the GUI editor basically set the bar for all future RAD development.
[/anecdote]
Read some of Joel Spolsky's articles and you'll feel better about yourself. From his article Working on CityDesk, Part Three:
Visual Basic is an extremely productive way to write code, especially GUI code. Want bold text on a dialog box? It's one click in VB. Now try doing it in MFC. You have to create a subclassed control, it's a big mess, you have to know all about LOGFONTS and Windows window subclassing and a bunch of other things and you need about three lines of code once you have the magic class.
But many VB programs are spaghetti, either because they're done as quick and dirty one-offs, or because they're written by hack programmers without training in object oriented programming, or even structured programming.
What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines. The code looks pretty good, it's object-oriented and robust, but you don't waste time using tools that are at a level lower than you need. I've spent years writing code for C++/MFC and years writing code in Visual Basic, and let me tell you, VB is just much, much more productive.
This simplicity attracts a lot of new programmers. Saying there are a lot of bad programmers using Visual Basic does not mean Visual Basic is a bad language; it simply means that Visual Basic is accessible to bad programmers (AKA new programmers).
I work in a place where all the code is C#, not VB .NET. One developer wrote most of the code. You know how he achieved this feat? Easy: He copied-and-pasted all over the place. A given method might have anywhere from a few to hundreds of copies throughout the system.
Good developers can be good in any language. Crappy developers can be crappy in any language.
Also just to note that VB, VBA, and VB.NET are all three different languages even though they might share some similar syntax. There's no real difference between VB.NET and C# (besides the keywords/syntax), so we shouldn't lump VB (6 and before) and VBA in with VB.NET.
The real problem that many programmers have with "VB" (just say all 3 of the languages) is really more about the people using it. Most of the time "VB" programmers have less formal education and write sloppier code. That's not true for all "VB" programmers (and that doesn't mean there's not sloppy code written in C++, Java, C#, etc.). It's just the typical expectation that someone who doesn't use VB has when they hear about VB programs.
Meh, these are just religious bigots.
There is no one true language, and most experienced folks not only know that, but instantly recognize these statements as a glaring sign of inexperience.
Average developer quality seems to be inversely proportional to popularity of language * ease of use of language. VB is very easy, and is/was widely used.
This is because
A) there's a demand for coders in popular languages, so every employer has to either lower their standards, raise their pay or go without developers.
B) people without a clue can still appear moderately productive in easy to use languages. There are enough libraries and GUI tools that they can slap together something that looks useful, even if it's complete garbage under the hood.
There's nothing inherently wrong with VB when used in the domains it was intended for, by people who know what they're doing. The same is true for almost any tool/language.
I dislike the language, but that's mostly because I worked with a vb-like language which stripped out absolutely anything that might be considered an advantage and forced "best practices" that really didn't make sense.
The biggest problem I have with VB is that there is an almost direct track from clueless non-programmer -> part time Excel/Access scripter -> VBA "guru" -> VB "programmer" -> lead programmer on the most important project in the company.
Honestly I wouldn't have believed it if I didn't see someone follow that path right in front of my eyes. I even tried to mentor the guy so that he would be familiar with OOP, exception based error handling, etc. but he just dug his head in the sand and wrote everything procedurally because that had always worked for him.
I have had a chance to work with VB.Net and as long as I treated it like an object oriended .Net langauge first and VB second it wasn't so bad. It would never be my first choice for a new project, though.
I'm visiting SO in between writing VBScript code and that statement really rings true to me -- I am currently a circus chimp. If you don't know anything else, VB and its variants seem like great languages.
In my opinion, the reason for the negativity is one basic statement -- On Error Resume Next. This makes bad code a feature of the language. If it didn't have this, it wouldn't have near the bad publicity...
Most every developer I know has worked at one point or another with a VB developer, or a developer with a heavy VB background that just didn't have a clue. Unfortunately, as with most things, all we remember are the bad things about something. So we relate VB to bad programming.
It is certainly not true that all VB programmers are poor developers. But when everybody has stories about "This one old VB guy I used to work with." The stereotype is spread.
This is sort of a "best language" question, but hopefully with enough of a twist to make it worthwhile.
As someone who only uses C and C#, I'm curious to learn a dynamic language to expand my knowledge. I don't know which to choose.
The thing is that my motivation isn't necessarily to create any "real world" projects, or projects that integrate with other systems, but rather just to learn.
With that said, for someone only familiar languages such as those I mentioned, and possibly ignoring obscurity and lack of support..
Which dynamic language would be the biggest departure?
Which would introduce the most novel concepts?
Which is the exemplar of dynamic languages?
I would suggest learning IronPython. As a language it will still be a significant departure for you, but you'll be able to use everything in the .NET framework that you're familiar with. (I usually think it's a good idea to try to vary just one aspect of development radically at a time... work your way through the different aspects one at a time, and you'll always be comfortable with part of what you're doing, which will help you learn the new part more quickly, IMO.)
Also, with C# 4 you'll be able to call into IronPython from your C# code, including using its dynamic features that way.
The functional languages (LISP, Scheme, etc.) are always worth checking out. They may be some of the bigger departures.
JavaScript is a great stepping stone to go from the C arena to the functional arena. From there you can mess around with JQuery, which, although not a language, forces you to do things in non procedural ways.
Another often overlooked language is SQL. It's obviously a niche language, and as Josh points out, not really 'dynamic', but acquiring a deep understanding of they way set based languages work can really progress a coder.
Careful, if you 'Learn' to much you may end up frustrated with the older languages.
Which dynamic language would be the biggest departure?
Which would introduce the most novel concepts?
I guess that would include Scheme, Erlang and Oz
Which is the exemplar of dynamic languages?
I'd say Ruby and Python
I would suggest any Lisp dialect or Smalltalk. These are dynamic and had heavy influence on the design of other, more mainstream languages.
They also include interesting concepts that are not found in other languages.
Another interesting dynamic language to have a look at is Lua.
It is hard to say, it is definitely a matter of personal taste in a lot of ways. I like learning Python but I am sure that you could learn just as many good things from Ruby about a dynamically typed language.
If you are used to C and C# then any dynamically typed language is going to be a departure. So I say you should use Python because that is what I like, and hopefully you will like it too. If you start using it and you hate it then try something else (like Ruby, Perl, PHP, etc.).
I would say that Lisp fits most, if not all, of your criteria. It's definitely a big departure from C/C++ and C#. It has got alot of novel concepts, and many would argue that it's hard to find a more dynamic language.
Barring Lisp, I myself would go for Ruby.
I'm going to have to vote for Common Lisp here. It is a highly dynamic language that can be adapted to just about anything. You get not only functional programming, but also OO, and even procedural if you so desire. And macros in Lisp are very interesting to study, since to my knowledge no other language has its equivalent.
Plus, developing in a functional style tends to help development in other languages as well. For example, I've noticed that I do OO primarily with immutable objects, thanks to concepts influenced by Lisp and Scheme. And with this, I've noticed an improvement in the stability and maintainability of my OO apps. Just my two cents.
I've been a C++ and C# developer for a long time, and recently started experimenting and learning other languages. I played with Ruby for little while and like it, but it wasn't what I wanted.
I ended up choosing Erlang. After reading about Erlang, I've decided that I really wanted to learn it. I'm not learning Erlang with any hopes of getting a job writing Erlang code. I'm learning Erlang only to become a better developer.
I really do like this language so far. It's only been about a month, and the syntax still gets me sometimes, but I can really see the power of the pattern matching and get excited to write it again. I struggled with the concept of everything being non-mutable at first. But this was mostly because I've "grown up" on C# and C++. C# is a great language and has some amazing tools, but you really have fun with some other languages, particularly something like Erlang. Just don't expect to land a job as a full time Erlang developer. (At least not yet).
For anyone curious, my hobby project is multiple player iPhone app connecting to an Erlang server. For a Windows developer, this has been a major change. But it has renewed my passion for programming, which really was my goal.
If you really want to go crazy but want things to at least be slightly familiar (I know that sounds like a contradiction but it's true), look at F#. It's a type-inferred language but it supports a lot of dynamic type properties. It's a functional language built on top of the CLR so you get full use of the .Net object system which is cool. Because it's a functional language, there are enough novel concepts to really work your brain.
If you really want to go for "biggest departure", Clojure might be of interest. It's a Lisp dialect built on the JVM. It's getting some pretty serious attention both in the Java and Lisp world. It might suit your purposes.
I would like to learn some VB because I am interested in a few industries that tend to use it exclusively. However, I find most resources far to slow in teaching the language and tools because they are aimed for those who haven't programmed before. Is there a good guide for programmers with experience in other languages like java and ruby?
Thanks,
Steven
The best way to learn is to fire up excel, or whatever version of VBA you're going to use (yes they are subtly different). Turn on the macro recorder, do some stuff, stop recording and then look at the code created. You'll immediately see some of the classes created, they can be looked at in more detail using the Object Explorer within the VBA environment. The syntax is just like any basic language. A couple of good practises, put the line 'Option Explicit' at the top of every source file, if not variables don't need to be declared, which is initially easy but leads to annoying bug hunts.
I'm not aware of a one stop shop to learn VBA, as you've already got programming experience it'll be a matter of unlearning some stuff - like OO, inheritance etc (yes I know VBA supports classes and interfaces but they're not the full enchilada).
BTW I noticed you tagged this as VB.Net, unfortunately VB.Net is not VBA - they're not related at all. Similarly VB and VBA are not the same although the overlap is about 90%.
Writing Excel Macros with VBA, 2nd Edition by Steven Roman, ch. 5-8 has a reasonably compact tour of VBA syntax, built-in functions, etc. You can find it on Google Books. Most of what it says should apply to VB6 as well.
There is also the Visual Basic 6.0 Programmer's Guide available for free on MSDN
However, MrTelly has the best advice if you're already familiar with programming in general. The Excel VBA editor, the macro recorder, and the F1 key are probably all you need, plus the basic help on specific syntax for control structures, etc.
This might be helpful.
Quite a few years ago a DDJ's columnist calling herself Verity Stob wrote a good summary of typical gotchas awaiting an experienced programmer starting developing with VB/VBA:
http://www.ddj.com/windows/184403996;jsessionid=HZEBCTTLEH5XGQSNDLPCKH0CJUNN2JVN?_requestid=378977
Excel is a good place to learn VBA.
A good resource is the book VB/VBA In a Nutshell
I've been studying OOP for quite a while now and I have a good grasp of the theory. I read the Head First book on OOP and, while it reinforced a lot of the theory, I found the case studies to be somewhat trivial.
I find that I'm applying OOP principles to my code each day, but I'm not sure if I'm applying them correctly. I need to get to the point where I am able to look at my code and know whether I'm using inheritance appropriately, whether my object is cohesive enough, etc.
Does anyone have any good recommendations (books, online guides, blogs, walk-throughs, etc.) for taking the next step in developing solid OOP skills?
I am working primarily in .NET (visual basic), but I welcome suggestions that incorporate various platforms.
Read Refactoring by Martin Fowler, and apply it to your own work.
It will take you through a litany of malodorous characteristics of software code that describe how to detect improperly constructed classes, and even more importantly, how to fix them.
Consider looking into Design Patterns. Although it seems like they aren't commonly used in enterprise applications (I've seen them more commonly used in API's and Frameworks than embedded into enterprise code), they could be applied to make software simpler or more robust in a lot of situations if only developers knew how to apply them.
The key is to understand the design patterns first, then with experience you'll learn how to apply them.
There is a Head First book on design patterns that teaches the concept pretty simply, although if you want a book that really covers design patterns in detail, check out the Gang of Four design patterns book, which is basically what made design patterns mainstream and is referred to almost every time the topic is brought up.
Design patterns can be applied in pretty much any object-oriented language to some degree or another, although some patterns can be overkill or over engineering in some cases.
EDIT:
I also want to add, you should check out the book Code Complete 2. It's a very influential book in the world of software development. It covers a lot of different concepts and theories. I learn something new every time I read it. It's such a good book that if I read it every 6 months to a year, I look at it from a different perspective that makes me a better programmer just by re-reading it. No matter how much you might think you know, this book will make you realize just how little you really know. It's really a great book. I can't stress how much you should own this book.
If you already have the basics, I believe only experience will get you further. You say you are not sure if you are applying the principles correctly, but there is no one correct way. Code you write today, you'll look at in 6 months time, and wonder why you wrote it that way, and probably know of a better, cleaner way of doing it. I also guarantee that after 10 years, you'll still be learning new techniques and tricks. Don't worry too much about it, it will come, just read as much as you can, and try and apply what you read in small chunks.
I am currently half-way through the following book:
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062
I cannot recommend this book strongly enough in terms of learning a real-life, professional-grade, practical approach to drafting and applying a well-formed and iterative design strategy before diving into code.
I, too, read the "Head First" book and felt that I was much better off for having read it.
After having a few years of working-world experience, I now view the Craig Larman book that I am recommending to be a perfect "next step" for me.
About the Presence of "UML" in this Book Title:
Whether you have positive feelings or negative feelings about UML notation, please do not let that influence your decision to buy the book (ISBN 0131489062) in either direction.
The prominence of "UML" in the title is misleading. While the author does use and explain UML notation, these explanations are extremely well-woven into relevant design discussions, and at no time does this book read like a boring UML spec.
In fact, here is a quote taken directly from the book:
What's important is knowing how to think and design in objects, which is a very different and much more valuable skill than knowing UML notation. While drawing a diagram, we need to answer key questions: What are the responsibilities of the object? Who does it collaborate with? What design patterns should be applied? Far more important than knowing the difference between UML 1.4 and 2.0 !
This book at times seems like it is "speaking to" a lead architect or a project manager. What I mean to say by that is that it assumes that the reader has significant control over the planning and direction of a software project.
Nonetheless, even if you are only responsible for some very small piece of your company's projects and products, I would still recommend this book and encourage you to apply some "scaled down" modifications of the book's advice to your piece of the project.
My OOP epiphany came from Grady Booch's book, way long time ago. Suddenly I realized why objects were good.
While polymorphism is cool, encapsulation is 75% of why objects are cool. It is sort of like an interface: you see the buttons but not the wiring. Before objects, only the most disciplined coders kept their grubby fingers off the internal bits of other people's procedures (it was called "structured programming").
Object make it easy to Do the Right Thing. Inheritance and polymorphism are little bonuses.
One way to learn about objects is to read other peoples' code. I learned a lot by reading the source code for the Delphi VCL framework. Even just looking at the documentation for Java will help you see what a single object class should do and how it is designed to be used by other objects.
Start a project of your own and pay attention when you want to sub-class your own classes and find that you have to go back and break up some protected methods so you can override just one piece of a process instead of replacing all of it. See how ancestors talk to descendants by calling abstract functions. In other words, go make a lot of mistakes and learn from them.
Enjoy!
Frankly, re-reading old David Parnas papers on information hiding helps me get in the right state of mind. The case studies may not be directly applicable but you should be able to get some useful generalizations out of them.
My epiphany happened when I tried to implement a very OO problem (dynamically and recursively building SQL statements) in VB6. The best way to understand polymorphism or inheritance is to need it and not be able to use it.
One thing that will definitely help you is working on a well-known, respected open source project. Either dig through the source code and see how things are done or try to make some additions / modifications. You'll find that there isn't one style or one right answer for most problems, but by looking at several projects, you'll be able to get a wide view of how things can be done. From there, you'll begin to develop your own style and will hopefully make some contributions to open source in the process.
I think you have to attempt and fail at implementing OO solutions. That's how I did it anyway. What I mean by fail is that you end up writing smelly code while successfully delivering a working solution. After it's written you'll get a feel for where things didn't quite feel right. You may have some epiphanies, and/or you may go and hunt for a slicker solution from other programmers. Undoubtedly you'll implement some variation of standard design patterns by accident. In hindsight, a light will click on (oh! so that's what a visitor is for), and then understanding will accelerate.
As others have said, I think tooling through some good OO open source code is a good idea. So is working with more experienced programmers who would be willing to critique your work. However understanding comes through doing.
You might want to try to read (and write) some Smalltalk for a while. Squeak is a free implementation that can show you the power of a fully object-oriented environment (unlike java or .net). All library code source is included. The language itself is incredibly simple. You'll find that java and c# are slowly adding the features well-known to Smalltalk since 1980.
Tortoise HG is extrodanarily well designed piece of OO open source software (written in Python).
If you already understand the basics, building something from scratch in a fully object oriented language will be a good step in fully understanding OOP software architecture. If you don't know Python, Python Essential Reference will take you through the language in full in a few days to a week.
After you understand the language take a look through the software above and you'll have all sorts of epiphanies.
To understand basically anything thoroughly, you need to have a decent knowledge of at least one abstraction level above and one level below it. In the case of OO, others have mentioned design patterns as the layer above OO. This helps a lot to illustrate why OO is useful.
As far as the layer below OO, try to play around with higher-order functions/late binding for a while and get a feel for how these relatively simple constructs are used. Also, try to understand how OO is implemented under the hood (vtables, etc.) and how it can be done in pure C. Once you grok the value of using higher order functions and late binding, you'll quickly realize that OO is just a convenient syntax for passing around a set of related functions and the data they operate on.