As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I recently came into some blogs saying that Linq to Sql is dead. and a few days ago I saw a discussion with some people saying that Silverlight maybe will take ASP.net place! ...I don't want to ask if they are true or not but it is so annoying when you wake up and found your languages and informations in the casket! (I think that Microsoft languages have the big part of this words). So what should I do in this case ? drop every thing back and start again with the new techniques or keep using the old stuff or what ?
A platform isn't dead because someone says it's dead. It's dead when it's no longer used, and in that case, it's obvious you shouldn't be using it either. Unless, of course, you're employed by a big company that has a big legacy system that needs further development using that "dead" technology.
Nothing ever really dies. Especially Microsoft stuff. I thought I had wasted 10 years as a FoxPro dev (not even VFP!), but this helped me get jobs, even in related technologies like dBASE and Clipper, since those skills are harder to find.
Having said that, by all means keep up with the mainstream. Continuous learning is expected in this field.
In any case, neither of those claims (re Linq to Sql and Silverlight) is true.
First off, dont immediately jump to the assumption that what you read in a blog or in a tech magazine is true. If the 'old stuff' still works, whats the compelling reason to change? Basically its just keeping up with fashion. Use what you want to use. If you understand the basics of programming, you can adapt as needed when presented with new technologies.
Neither ASP.NET or Linq-to-SQL appear to be vanishing any time soon; however, this advice always applies:
Put pressure on Microsoft (or any other vendor, for that matter) to support products your business depends on.
If your business regularly purchases upgrades to its Microsoft stack, MS will want to make you happy. Get involved at Microsoft Connect, contact your MS representative, and be involved. The safest path to maintaining support from MS is by participating in their process. (It's why Windows XP remained supported long after MS announced support would end.)
Simple answer: Be sufficiently broad in your technical abilities.
As a hiring manager, I'm more concerned that you know how to write good programs and that you know how to get answers to your questions, than I am that you spent 10 years focusing on a specific technology.
For example: If I'm hiring for an MVC2 position, I would gladly take a seasoned Microsoft web developer with webforms experience and some MVC2 exposure over an unseasoned and unskilled programmer that's been working in MVC2 since it came out.
Many programmers are keen to try out new things. The statement "Technique X is dead", means just that someone tries to convince himself or a group, that investing more time into something else seems worthwhile.
To really kill a technology you would need to remove all related downloads and available knowledge or relicense the software in some form that makes usage impossible.
When a group of people shout that X is dead, they are just moving to Y. If you can still hire X programmers, you are not in big trouble.
Don Box once said "If your this kind of people that start working with a technology when it's dead, it time for you to start using COM". He said that to introduced .net an confirm that way that COM won't be further improved. See ? "Dead" means it won't evolve as much as other anymore but definitely not that we should't use anymore.
Don't jump to conclusions based on (non-authoritative) blogs. People have opinions, and that's all they are. Until the vendors of the technologies you're using come out and say it, proceed with caution.
I'm not a .Net expert by any means but I think there's a reason for not using Linq for SQL queries since a dedicated ORM approach will most likely be faster and more configurable. As far as Silverlight, it's just a subset of WPF which is a GUI framework. They possibly wish that silverlight would take over some processing from the server side but I doubt they'll get that sort of market penetration.
That's life on the cutting edge... You got into this business because you liked the latest technology, right? Well, don't look back, look forward. Before your favorite technology even has the sniffles, you should be looking at what's going up. If you study up on the latest technology, you won't even notice when the old stuff go away.
Software development is all about learning things so that you can build things that will be thrown away and replaced with newer things some day! If you don't want to commit to continuous change, you're in the wrong field! :-)
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Not sure if this is the best place to ask or not but if it gets closed down oh well. I am in computer programming and starting on my first work term. I will be doing 2D game programming for iPhone in objective C. I was just wondering if you had any tips for learning how the code works on a big project. In college I have never worked with something in terms of this scope. I am used to a project with maybe a dozen source files while what I'll be working on has hundreds. It is very overwhelming for me.
Any Tips would be appreciated. Thanks very much
This is how I do it. Opinions and methods may vary.
Generally speaking, I find the best way to learn about a system is to go through the code while the app is running.
Pick a significant place in the UI (the startup screen, some other screen).
Find the class for that view. Generally just ask a senior developer. Developers are happy to give a pointer (no pun intended) to someone who wants to learn by himself instead of having to explain everything.
Place a breakpoint in that class and run the app in Xcode until you hit your breakpoint.
Then start tracing in there to see how things happen.
Repeat the process at different spots in the app and soon you'll get a general idea of how the app works. Then it's a lot easier to catch the details.
If the system is really enormous (like an enterprise app that runs on multiple systems), then a diagram showing all the architecturally significant pieces would probably help. For an iOS app, it's probably not needed.
Good luck...
I am a 3rd year computer engineer who has done four work terms, and I can offer the following :
Some general advice:
Compartmentalizing your approach is still very useful on a big project, as in a small one. The more specific parts you focus on at a time, the easier it will be to understand them. This is not always practical due to interdependence of programs, but it is still possible to, say, work on the graphics portion alone, or the character's movement algorithm, etc. You should know that in the past that it was possible for an educated person to know the sum of human knowledge, but that is impossible today. Even senior engineers/programmers have specific areas of expertise, and other areas where they are fuzzy. Find what you most enjoy/are talented at, and devote time to that.
A basic foundation is important. Study the basic ideas of loop structures, classes, methods and the like, and know them like the back of your hand, so when applying them across languages/platforms, all you need to do is refresh yourself on the syntax. The same basic ideas apply across a range of languages.
Most of all, do not panic. It is your first work term, and you are assigned mentors/supervisors, as well as working with a team. Doing it alone would be difficult, so network well with your teammates/superiors so you can all learn from each other, divide the work, and lessen the stress on yourself!
Good luck! :)
Short Answer :
Read less, do more, then read when you get stuck. In my opinion, that's the best way to learn any new language and also someone said :
"We learn by doing, there is no other way".
Long Answer :
Rule 1: Relax.
Rule 2: You gotta understand that this is not easy stuff to master. That is why people who do get paid really well. If you had an idea you could bang this stuff out in a couple of weeks with you need to dump that. Plan to spend months working up on it.
Rule 3: Understand that the Apple API is HUGE and it is always evolving. There is enough content to learn something new Everyday.
Rule 4: The fewer programming languages you've had to learn, the harder it is to learn new ones. You will learn slower than someone else who has learned half dozen languages/APIs already.
Rule 5: Don't be afraid to use repetition and brute force. I think the thing that slows novices down is not learning the behaviors and methods of common foundation classes like NSString, NSArray, NSDictionary etc.
Rule 6: As a learning exercise, copy-pasting might not be the right thing to do. If there's an Apple example of how to do something, rather than copy-pasting I tend to rewrite it manually. I find it sticks better in my mind.
Rule 7: Use any resources you like. There are no rules on how you should learn.
Rule 8: iPhone is a memory constrained device where network and local storage access is slow. Parts of your application can be unloaded at any time, your application is responsible for maintaining it's memory footprint (not the user), and an event (phone call, memory, etc.) may require the app to respond accordingly and quickly.
Rule 9: It isn't about you. It isn't about your code. And it isn't about your code doing this or that. It's first about the user and responding to the user. It's second about your code responding to the framework. You don't usually tell the framework what to do. It asks you for things when it needs something. You sit and wait for it to talk to you. You're not in charge. You don't control the runloop; it controls you. You register to be told when things happen, and you indicate that you're the object who knows something about something (data for a table for instance). And then you let go, and let Cocoa do the rest. It's a very different world. I like it very much.
Rule 10: Relax.
When I'm coming to a new Xcode project, I open it up in OmniGraffle Pro. If the project is well organized, you'll see a nice diagram with a summary of the classes, the methods that are present and a little bit of how things relate to each other, important enums to know about, and other helpful information for getting a good overview of the project.
After that, pick a point like #mprivat said and run it in the debugger and get a feel for how things run. I like to set breakpoints with logs of the breakpoint name and hit count (and maybe the value of some variable or parameter if it seems relevant) and automatic continue after a little while to avoid pesky timing issues that can sometimes creep up when the debugger pauses execution. I use breakpoint logging so I don't have to worry about accidentally committing clutter code. (Be careful of pulling new code though because breakpoints don't move with your changing codebase. :))
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What do you think about both?
I began reading a book about Catalyst, and found it pretty complex as compared to Dancer.
so now I'm giving Dancer a try, and it looks easier to learn and more "human friendly".
I think David's comment is very accurate and excellent. However, as someone who has done development in both but is not a developer on either perhaps I can be slightly more objective (and technical) in what the differences are.
Both frameworks provide a variation on the Web MVC paradigm.
Catalyst's main level of abstraction is the Controller. Catalyst expects you to break separate logic out into separate packages in some logical fashion (Login code goes here, Registration code goes there, Search functionality over here). This works incredibly well if you have a team of programmers since each of you can work on separate files and not step all over each other during merges. Catalyst provides a lot of tools for making the Controller logic extensible and flexible, I think the premier example of this is Chained actions which let you split up and build a complex flow for any given request. The downside is that it becomes very seductive to put your business logic into the Controllers and you end up with very fat logic in the Controllers where it (theoretically) belongs in the Model.
Dancer's main level of abstraction is the Route. My experience with Dancer is this leads to much smaller applications. Partly my experience here is tinged with the fact that I have dealt with several thousand line applications in Catalyst but I have yet to write a Dancer app that is longer than 200 lines (with a much smaller scope). I think however that this experience holds true. The push in Dancer is in keeping the Controller logic very thin because it doesn't have the same tools for managing complex behaviors there that Catalyst does.
Honestly I've enjoyed working in both of them. They both provide different opinions on what writing a web application is supposed to be. I would, given the time and inclination, recommend learning both ultimately.
This is a somewhat subjective question, but I'll try to give you an answer in an objective way. First things first, a disclaimer: I'm part of the Dancer development team, so my opinion should of course be considered somewhat biased :)
Catalyst is more widely used than Dancer, and so there's more community support behind it - if you were to look for contractors with experience working with either framework, say, you'd be more likely to find developers who've used Catalyst. So, if you're looking for commercial support, that would be a good reason to choose Catalyst.
Dancer is a younger project, and targeted more towards smaller projects, making getting up and running quick and easy, and trying to stay out of your way. That's not to say that Dancer isn't suitable for larger projects, however; the same habit of staying out of your way means you can organise your project in the way that suits you.
However, it has picked up a lot of support, and there's a growing community of helpful users and developers on IRC and the mailing list, and more and more useful plugins being released all the time. As with Catalyst, Dancer is designed so that you can pick and choose your preferred template engine, session storage backend etc, and it's easy to extend the framework by writing your own plugins if you need to.
For user testimonials to see what people say about Dancer, see the section at the bottom of the homepage on the new website: http://www.perldancer.org/
In the interests of showing other options, there's also Mojolicious, another modern Perl web framework which has been gaining in popularity lately.
Catalyst provides the same abstraction that Dancer does, Dancer's strength or rather Catalyst's weakness or rather Dancer's weakness is in how Catalyst forces the developer to adhere to Perl OO best practices and the MVC design pattern. After doing webapps for a while, this will all become apparent.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
On my first job interview, I was asked why did I build my own CMS? Why not to use one of existing CMS, Wordpress, Joomla, Drupal...? At first, I was stunned. I couldn't immediately recall all of my reasons for building my own CMS, but this was definitely one of the main reasons: It's my code and if I want to change something in that CMS (which I often have to do, because each website I build needs CMS with different functions) it's not a big problem. For some time I've been using Wordpress and one of the main things that distracted me from using it was discovering bugs in code that wasn't written by me and this bugs were often, especially if I made some changes to CMS or added a plugin...
Here, I can find these 8 reasons why NOT to build own CMS:
It won’t meet users’ needs
It’s too much work
It won’t be a standard solution
It won’t be extendible fast enough
It won’t be tested well enough
It won’t be easily changeable
It won’t add any value
Create content, not functionality
Quote from the same page:
So the main question to ask yourself
is: ‘Why am I really trying to
re-solve a problem that has already
been solved before?’
Well, I definitely agree that it's hard to invent CMS that hasn't been already invented, but on other hand, I think every CMS is (or should be) individual... it maybe won't have a million of functions, it will have 3 functions but their usage will be clear (to a user) and do all that one site needs to have. I think also that it is not good to give to a client a CMS with a lot of functions that are never used and it looks probably more professional when website and CMS together look like one product.
I would also like to comment some quote parts:
"It’s too much work" - I agree, but when using existing CMS and customizing it to website needs and can sometimes be very hard job or mission impossible.
"It won’t be easily changeable" - I disagree with this one.
What is your opinion on this one, why did you develop or didn't develop your own CMS?
Ile
This is an interesting question that applies to most development, not just when building a CMS.
In general, I would say that it's a bad idea to reinvent the wheel (and most of your 8 arguments are correct in most cases), but there are exceptions. The first one that comes to mind is one from Joel Spolsky, In Defense of Not-Invented-Here Syndrome:
If it's a core business function -- do
it yourself, no matter what.
The point is, if you're making your money directly from building content management systems, you should not take one from someone else and tweak it until it fits you. You'd rather be in full control over your own product.
Edit:
Also, don't forget that the urge to reinvent things stems (among other things) from a fundamental law of programming:
It's easier to write code than it is to read it
This does not mean that we should take the road that appears to be easier but it explains why we fall for it. Take the challenge and actually read some code, rather than write it, from time to time.
I would build a CMS because it can be fun and a great learning experience.
However, any open source CMS can be customized to any client's need. The biggest problem is that you have to understand how that CMS works in order to be able to change it well.
Either way you would be faced with quite a big task, but I must agree with those who say that you shouldn't start from scratch (unless you are doing it to learn some new technology) exactly for the reasons stated in your question... As they say, don't reinvent the wheel unless you want to learn about wheels.
I've found it works when the context of the project is larger than just a 'content site'. I've worked on a number of real estate sites where the bulk of the content is coming in from data feeds, or already existing in databases that have had their structure set up long before you were involved. Really, we only had a handful of BS 'content' pages that made up the site that were rarely updated. What they really needed was a simple interface to data entry. It was far easier to build some one off components than try and shoehorn an existing system on top of an out of the box CMS.
Like others mentioned though, you must consider overall requirements. Is there workflow involved? Dynamic navigation? Then I'd start leaning more towards out of the box CMS's, but many times people say they need a CMS, when they really just need a WYSIWIG interface to a database. But sometimes not...
It seems to me that the biggest reason NOT to build your own CMS (besides security issues) is lack of support and upgrade path. I consider it a disservice to clients to put them on a custom CMS and then have to rely on you only support and updates. Even worse is having them pay for the development of the custom CMS - they are paying you to reinvent the wheel no matter how simple the site requirements are.
There are plenty of CMS options out there that will allow you to add your own custom extensions if your requirements are beyond what is built in.
The best reason (possibly only) to build a custom CMS is to learn a language well. Building a CMS is a great way to learn web development, but it's not a great way to service your clients.
As a team leader that is always being pushed to do more with less, I too ask the question "why would you write your own?" There are more CMS packages out there than there are programming languages and I find it difficult to believe that you cannot find one that meets most (if not all) customer, business and cost requirements.
If you find that code changes are needed, opt for an open source solution, make your changes and share as needed or desired.
I do know that many times a CMS systems is NOT what is needed. Many customers need a Content Editing System. What I mean is that someone technical puts a site in place and the customer adds/edits/removes pages. The pages are already well designed and formatted. In these cases, I can see where it may be quicker to design & implement something from scratch rather than chopping down a CMS with access rights or removing/hiding functionality.
Unless you're building one for the experience, there's only one real reason for building your own: It's cheaper and/or easier than using one on the market that meets your requirements.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As an artist and musician, I often want to sit down and just let the code roll like a piece of free-form poetry, but I've found that doesn't work as well as when I have a set goal in mind. I've been experimenting lately with setting up tiny, fun goals for myself, not unlike how an artist would sketch a quick still-life, but I wonder...
What do others do when they want to code for fun, without the bondage of an already-committed project?
Design work, I find, flows much easier than just coding. I find that coding is often more of just implementation of a good design; I really like to just sit down with a pad of paper and a pen (and likely a bottle of wine) and work out an interesting design.
Project Euler is where I'm having fun at now. I can go at my own pace and work on the problems that interest me. Also, work in any language I choose.
Write documentation when coding doesn't come easy - coding will quickly seem much more appealing!
Going for a walk outside.
I tend to map my idea or build a structure in a MindMapping tool like MindMeister. And it's great for a team because it can be edited in real time by multiple persons!
I like to pick up a new language and learn how to express ideas in it. This usually has the benefit of showing me what I like and don't like about the languages I currently use. I usually pick some little tool project I've been wanting to do. Using the new language angle get's me motivated
My most recent 'new language' is Scala, in this case it will likely become a langue I use.
I like writing on whiteboards. Great for db diagrams, task lists, feature lists, (other lists,) random ideas, notes, etc. (db diagrams being the biggie for me)
Python is great for just getting things going on an idea and having the language (usually) behave like you would expect.
While it may have its drawbacks, it sounds like a great fit for what you are describing.
So to answer your question, the Python Challenge is entertaining and often gets me thinking about little things that would be fun to code, probably because it exposes you to different types of problems.
I like to code.
I like to find something interesting, code it and then see it works.
It does not have to be a project per see, it's good enough if it does something, like use Google api to get picasa albums, change song in iTunes or get details of current iTunes song, automate downloading of document from web site that is behind login and requires cookies and all that stuff, data parser in python, simple app on Mac, core data application, google codejam problems, topcoder.com problems ...
I like to learn new features of some language or some new language/technology/patterns/tool :-)
Usually I will work in Photoshop for a while. Get creative and try to come up with a new design that's not constrained by any code. Maybe even find something inspiring on the web for some new design ideas... then try to implement the design in code. That's the fun and challenging bit.
Use the REPL.
You figure out broadly the sort of thing you need to do - what APIs you need to use, what data structures you need to handle - and then prod them interactively until they start making sense. A ton of languages I use now have REPLs: Ruby, Python, Scala, Java (BeanShell, or JRuby/Jython etc.), C# ('csharp'), PHP (Facebook have made a REPL for it), Smalltalk (GNU gst) and, obviously, LISP/Scheme.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm about to start a project for a customer who wants CMS-like functionality. They want users to be able to log in, modify a profile, and a basic forum. They also wish to be able to submit things to a front page.
Is there a framework or barebones CMS that I could expand on or tailor to my needs? I don't need anything as feature-rich or fancy as Drupal or Joomla. I would actually prefer a framework as opposed to a pre-packaged CMS.
I am confident I could code all this from scratch, but would prefer not to, as something like a framework would significantly cut down on my time spent coding, and more on design and layout.
Edit: I should have been more specific. I'm looking for a Content Management System that will be run on a Debian server. So no .net preferably.
I think i may end up going with Drupal, and only adding modules that I need. Turbogears looks a bit daunting, and i'm still not quite sure what it does after it's 20 minute intro video...
TinyCMS doesn't look like it's been touched since... 2000?!?
I think the best is CMS Made Simple. Seems like drupal takes awhile to customize.
http://www.cmsmadesimple.org/
tinyCMS is about as barebones as you can get. (edit: fixed link, I had gotten a little click happy and linked to the wrong thing)
#modesty, I would definitely NOT use SharePoint, as it is anything but barebones. It is a fairly expensive product (especially when compared to the many free alternatives), and it has quite the learning curve to do anything interesting.
Woo, another Debian nut!
I think you need to be a bit more specific here, Forum != CMS. Is this for internal company or external customer use? What language(s) do you know/prefer? There's no point in recommending a Perl or PHP framework if your language of choice is Ruby. Do you need to plan for scalability?
What's wrong with Joomla or Drupal? I would argue that they can be successfully used on small sites. Maybe a framework isn't what you're looking for, maybe you just need a library or two (eg. PEAR?). If you need something smaller, maybe writing your own backend library that you can reuse for future projects would be a better solution.
For a one-size-fits-all framework have a look at Turbogears. ("it's a big hammer, that makes every problem look like a nail")
I've been obsessing over TikiWiki lately. Although it has "wiki" in the name, its full name is "TikiWiki CMS/Groupware" and it's an interesting piece of software. It has a real everything and the kitchen sink feel. It includes support for wiki, blogs, articles, forums, and files out of the box (and a ton of other stuff too). I think the real appeal to me is that most of the stuff can all be integrated together, wiki pages can include other wiki pages and articles (which is more useful than you might think). It's in RC stage for release 2.0 and is still missing a ton of features, but I think I might keep using it and contribute some of the features that are missing, it's a really interesting base right now.
The Mozilla support site is implemented using TikiWiki, for an example of a really beautiful implementation.
Drupal's include system should keep everything relatively lightweight as long as you only include what you need. Despite the fact that it comes with a smattering of modules, what you choose to enable is all that will be included at runtime. If you have to get under the hood and make modifications, I'm also a firm believer that Drupal is a more friendly and elegant system than Joomla. We use Drupal at my work-as much as a framework as a CMS-and it has proven pretty reliable in keeping development practices at a high level.
I realize I'm a couple years late to the party but I was looking for something like this myself and ran across this post while doing Google searches for 'barebones cms'. Along with this post, this turns up:
http://barebonescms.com/
There is also a forum on that site.
A similar combination could probably meet or exceed all of your criteria. Although, as others pointed out, you weren't particularly specific on the details.
While the original author is probably long gone, hopefully someone else finds this useful.
I would suggest PmWiki, it's something between a framework/wiki. By default there aren't even users, just different passwords, for different tasks, but using PmWiki Cookbook 'recipes' You can add additional functionality.
You can check their philosophy to get main idea what it's about.
If you want a Rails solution, Radiant CMS is a good option. It's simple, elegant, extensible and, of course, comes with all of the benefits of being based on Ruby on Rails.
if you are looking .net you can take a look at umbraco, haven't done much with it (company i work for wanted much more functionality so went with something else) but it seemed lightweight.
Edit : if the customer wants a tiny CMS with a forum, I would still probably just go Drupal with phpBB or simple machines forum, almost positive they can share logins. Plus tomorrow the customer is going to want more and Drupal might save you some work there.
Might want to check out Drupal.
Here are the details of the technology stack that it uses.
I have never used it so I can't vouch for the quality etc but definitely worth a look.
how about you use drupal but scale down and code it according to your needs.
definitely will be faster than code-from-scratch-with-framework
I have been working with Joomla for some time and I believe it one of the best CMS for starting off a Website. I have tried others a lot, But Joomla is better because it has Numerous Extentions (Components , Modules) and also its very Easy to Customize. You could also look at the Community Builder Extension for joomla.Other requirement like Chnage Fronpage Articles etc is a Breeze....
joomla.org
For some reason Joomla Does not Suit you try Drupal.
Wordpress is a very powerful but simple CMS.
bbPress is a very simple but integrated forum (easy, Wordpress user account integration with cookies and all).
Since you have programming experience you may find Wordpress to be the perfect match (PHP, MySQL) with plenty of plugins and hooks to help you achieve what you need. For example, there is a featured posts plugin that will put selected content on the front page.
I need to jump on the Umbraco bandwagon here. As far as ease of use from a developer standpoint goes, there is nothing easier than umbraco and v. 4 has full master page support and a tone of other stuff... and it's free.
For windows take a look at the DotNetNuke is asp.net based, free and open source and easily skinned and modified, there is also a thriving market in add-on modules. In addition most hosting companies offer it as a pre-installed application
Expression Engine is fantastic. It's free to download and try but you must purchase a license if you are making a profit with it.
WordPress actually has a forum plugin - it's nothing fancy but it's there. It handles user management et al and has a big community for plugins and themes. I think it is probably the easiest CMS to install & run (I've done some legwork here). There are plugins that update the core & plugins automatically (take that Drupal). I've tested these and they seem pretty solid. As usual - backup beforehand.
For .NET MojoPortal looks pretty good and is lighter than DNN. I saw the edit but thought I'd include this anyway since it looks like it's worth checking out.
Drupal is a language unto its own - I wouldn't tackle it unless you're going to do so with some regularity, otherwise it's just another different framework to learn. The uplink into my brain is at capacity already so I gently pushed it aside. The themes tend to look the same too.
Joomla may suit your users for usability.
I'd go for a pre-made framework myself because it would have a community and expansion capacity. What your client wants today will pale into insignificance tomorrow.