I'm looking to learn AutoCAD. I have found several videos online that relate to 2006 AutoCAD - but is there a difference to any of of the versions. I have seen job postings asking to know AutoCAD 2008 -- what happens if I only know 2011 or even 2010. Can I work with 2008? Is there a difference to any of this versions or years?
AutoCAD is a lot like Windows... They have major releases and minor releases, so the change from 2006-2007 was a significant change. They roll out a major release every couple years or so. Still, it just depends on what you're doing. If you've got to draw a line, it's drawing a line, and that doesn't change a lot from one release to another. Some companies use the "features" of the software, but lots of them don't. My advice: get an account with Autodesk University here and click through the online classes. Look for some basic AutoCAD classes. It will really help you learn about the software and the changes made from one release to another. Also: If you get an interview for a CAD job, they will probably give you a test... usually it's just drawing something in CAD from a piece of paper. I had one of these where I had to use a version of AutoCAD called Architectural Desktop. I had never even seen Architectural Desktop before, so I asked the person interviewing me, "Where do I start?" He showed my how to start, and I actually got the job. That was 7 years ago and I still work for that company today. Use the free tutorials to acquaint yourself with the software, but don't be intimidated by it. If you get as far as testing in an interview, do your best, and don't be afraid to ask questions.
If I recall correctly 2006 was still a version without the ribbon interface. In any case, the most significant change in user interface in the recent years was exactly that - caused quite a bit of stir when it was first introduced, and many drafters still switch to "old" toolbar.
As far as changes go, yes, there are quite a few. But as Asheville said, they more relate to some advanced features of the software, which at this time you will probably not be using. My advice would be to start with some of the newer versions ("the ribbon" ones) and adjust yourself to it. After you've grasped the fundamentals, and found your way around, and wish to expand your knowledge in a more systematic way (although we all know this almost never works :) I would go to one of the either; "Autocad xxxx Bible", or "Mastering Autocad xxxx" books where xxxx signifies the version. They are quite heavy (figuratively and literally) and you can skim through as you progress. Most of the things in there you probably won't need, unless you find yourself working in a large draft office which has it's own way of organizing data, drawing styles, ...
Autocad forums are also a good place to ask questions (search first !) ... the community there is quite helpful.
what is the future for excel vba? it seems like excel is on its third or fourth version of trying to get VSTO as the mainstream solution here. Is there a clear strategy? is vba going to die anytime soon?
I can tell you that it's still supported in Office 2010. The VBA library itself actually got an for the first time since VB6. Office 2010 has introduced support for 64 bit features and a few other small things.
One item of potential concern is that some advanced VBA applications make use of 32 bit ActiveX Controls that may not ever have 64 bit versions released. But for most day to day business applications you should be fairly OK.
Office is very important to Microsoft, so they aren't going to do anything to hurt their business on purpose. I would imagine that whatever they do there will be a roadmap to help people transition to the "new" way.
As for how long it will be until such transitions take place, consider that many business major businesses are still using XP/Office 2003. And we know VBA is supported in Office 2010. If that pattern holds for Office 2010, then in 2017 there will still be major companies on Windows7/Office 2010.
So all in all I wouldn't loose too much sleep over it. Just make sure you hook into Microsoft's developer programs so you can keep an eye on it, and make sure your skills don't go stale.
The simple answer is "no, its not going away anytime soon." Microsoft has been clear on this point. There are multiple citations on this, such as:
Clarification on VBA Support
This is also a good read: The future of VBA looks a lot like VSTA. Or does it?
I've never been a big fan of MFC, but that's not really the point. I read that Microsoft is due to release a new version of MFC in 2010 and it really struck me as odd - I thought MFC was dead (no ill intention, I really did).
Is is MFC used for new developments? If so, whats the benefit? I couldn't imagine it having any benefit over something such as C# (or even just c++ using Win32 APIs for that matter).
There is a ton of code out there using MFC. I see these questions all the time is this still used is that still used the answer is yes. I work in a very large organization which still employs hundreds of people who write in cobol. If it has ever been used in the enterprise it will continue to be used until there is no more hardware to support it, then some company will pay someone to write an emulator so that the old code will still work.
The navy still uses ships with computers with magnetic cores for memory and I'm sure they have people to work on them. Technology once created can never not be supported. its a bit of the case of Deus ex machina where large organizations aren't completely sure what their system do and have such an overriding sense of fear of brining the enterprise to its knees they have no desire to try out you new fangled technologies(BTW we pay IBM for best effort support on OS2).
Also mfc is a perfectly acceptable solution for windows development given it is an object model which wraps the System API which is pretty much all that most people get out of .net.
As an addendum and since this question is up for a bounty this is a quote from MS regarding mfc in VS 11
In every release we need to balance our investment across the various areas of the product. However, we still believe that MFC is the most fully-featured library for building native desktop applications. We are fully committed to supporting and maintaining MFC at a high level of quality. Here’s a short list of some of the issues that we fixed in MFC for Visual Studio 11:
Here is the link if you want to read the full post
Coolness does not factor in choosing the technology for a new system. Yes if you are a student or want to play around you choose whatever you want.
But in the real world each technology has advantages and drawbacks. A year ago one of the teams started a new project, it was decided that it will be done in MFC.
The reason is very simple: they have to use windows api a lot for low level operations with the printer, internet explorer and god knows what else.
C# was not even in the game, the decision was made between MFC and QT, both had the needed functionality, both could easily integrate the low level functionality, the only difference was that some team members already had MFC experience, so they didn't have to waste time and money with trainings.
Let's suppose they choose C# and WPF:
-1 You have to wrap all native C++ and ASM code in a DLL (ouch this can be painful, instead of coding you write wrappers).
-1 You probably need two teams now, one for the ui one for the winapi stuff. It is very unlikely that you'll find a lot of people able to write both C# and winapi stuff. Agreed that either way you need someone to make the interface pretty (programmers usually suck at this and they cost more) but at least with C++ only code, there is no more wait time between two teams, need a ui modification, no problem I don't have to wait for the ui designer, he will make it pretty later.
+1 You can write the UI code in C# and WPF, let's say the UI development is faster, but the UI is only 1/4 of the project, so the total gain is probably very small.
-1 Performance degradation: for every small operation you can't do in C# you call a external DLL (this is a minor issue since the program runs on 8GB RAM Quad Cores).
So in conclusion: MFC is still used for new development because the requirements and the costs decide the technology for a project and it just so happens that MFC is the best in some cases.
MFC is still used for some new development, and a lot of maintenance development (including inside of Microsoft).
While it can be minutely slower than using the Win32 API directly, the performance loss really is tiny -- rarely as much as a whole percent. Using .NET, the performance loss is considerably greater (in my testing, rarely less than 10%, with 20-30% being typical, and higher still for heavy computation. Just for example, I have a program that does Eigenvector/Eigenvalue computation on fairly large arrays. My original version using C++ and MFC runs one test case in just under a minute on our standard test machine. Some of my coworkers decided it would be cool to re-implement it in C#. Their version takes almost three minutes on the same machine (quad core, 16-gigs of RAM, so no, not "legacy" hardware). I'll admit I haven't looked at their code too closely, so maybe it could be improved, but they're decent coders so a 3:1 improvement strikes me as unlikely.
With MFC, it's also easy to bypass the framework and use the Win32 API directly when/if you want to. With .NET, you can use P/Invoke for that, but it's quite painful by comparison.
MFC has been updated with every release of Visual Studio. It just isn't the headline feature item.
As for new development, yes. It is still used and will continue to be so (even though I, like you, prefer not to). Many organizations made the technology decision years ago and have no reason to change.
I do think you are talking about well-established shops though, folks with more interest in maintaining / enhancing what has been written rather than stay on the cutting edge.
The release of the MFC Feature Pack (one or two years ago, iirc) was the biggest extension of MFC since around 10 years and it gave quite a new boost to MFC development. I guess a lot of companies decided to maintain their legacy applications, push them forward and delevelop new applications on its basis.
For me (as someone who has to maintain a large MFC application) the bigger problem is the decreasing development and support of (Microsoft and third-party) components rather than MFC itself. For instance is porting to 64bit not easy if a lot of old and unsupported pure 32bit Active-X components are assembled in the application.
I did a project last year based on MFC. I'm not sure why MFC was chosen, but it was adequate for making a virtual 3D graphic user interface—a building management security system—with 10 frame per second refresh rate run efficiently on win32-based PCs dating back to the mid-1990s. The executable (which requires only core win32 system DLLs) is less than 400K—not an easy accomplishment with modern tools.
There are advantages to staying away from managed code (maybe you're writing a driver UI, or doing COM).
That and there's tons of MFC code out there. Maybe you work for Company X, and need to use one of the zillion DLLs they've been writing over the last dozen years.
I can think of one commercial software title that benefits from using MFC over C#: Wwise[1]. C++ is an obvious choice for the sound engine, so it makes sense to write the authoring tool in C++ as well. It's both an authoring tool and a sound engine. They could have built the authoring tool in C#, and the sound engine in C++, but if they're debugging a problem with the sound engine that's reproducible through the wwise authoring tool, it's easier for them to see the whole call stack just like that.
I think there's some ways of doing a mixed call stack nowadays, but maybe that wasn't there when they first made Wwise? In any case, using MFC ensured that they wouldn't need a solution to the problem of mixed call stacks. The call stack just works.
[1]Wwise is built on MFC: https://www.audiokinetic.com/fr/library/edge/?source=SDK&id=plugin_frontend_windows.html
I've googled and not come up with much. Has anyone run across something like Resharper for Mono?
Not that I'm aware of, no. A few people have discussed it but nothing concrete has emerged. We've been trying to implement some of the low-hanging fruit among the R# features that matter to people, such as the camelCase completion list matching - please file enhancement bugs if you can think of any more!
Also, now that MonoDevelop is no longer GPL there's the possibility that JetBrains could actually implement a R# addin for MD, if there's enough demand. R# as whole is immensely complex, so I don't imagine anyone else could build a decent equivalent any time soon.
UPDATE: There is an experimental Resharper-like source analysis and quick fix feature built into MonoDevelop 3.0. It can be enabled in Preferences.
Recently I've been doing lots of weekend coding, and have began to really need a bugtracker as things are gaining speed. This is probably the worst case scenario because I basically have to let things cool down over the week,so I simply can't remember the bugs in my head. So far I've been using a text file to jot down bugs,but I'd rather use something a bit better.
The biggest points here are ease of use and very little setup time.Don't want to spend more than an hour learning the basics and trying to install something. Also in my case I'm on a Mac so that would help, but solutions for other platforms are welcomed as they will likely help others.
FogBugz has a student/startup edition that's free indefinitely, for 2 or less users.
Personally, I use Excel. (Wait, come back, I'm not crazy!) For a bigger / team project, I've gotten a ton of mileage out of Bugzilla, but that tends to be kind of overkill for a one-person project.
But, a well-organized spreadsheet, with columns for things like "status", "description", "code module", "resolved date," etc, gets you pretty close to what you'd need for a small project. Sorting a spreadsheet by column isn't anywhere near a search, but its a whole lot better than "find in text file."
Heck, if you use Google docs rather than excel, you can even publish the thing as an RSS feed and get it anywhere.
And, the major advantage is that the setup time and learning curve are both effectively nil.
Addendum: And of course, the instant your "One-Person Bug Tracker" becomes a "Two-Person Bug Tracker" you must switch to something better. Bugzilla, FogBugz, anything. Trust me, I've been there.
Trac or Redmine are both pretty good. I don't know how easy they are to set up on a Mac.
It's worth mentioning that FogBugz also has a free version for up to 2 users, which would suit you. It is hosted so there is no installation and you can use something like Fluid to access it in its own window.
I don't think you need a full blown bugtracker for your scenario.
Try tiddly wiki, store each bug in a tiddler and give them tags like 'open' or 'closed'.
There is no installation required (only one html file), and it's very easy to use.
And platform neutral.
If you're working on a LAMPP stack, then for ease of setup and use I would probably recommend Mantis. It's written in PHP / MySQL and the only installation involved was specifying where the database should be created and what credentials should be used.
Oh, and its FOSS.
I would suggest Omnigroup's Omnifocus - it's an excellent task tracker, and if you just make the mental leap from bug to task, I think it works famously for one man projects as well as being an excellent way to organize your no doubt burgeoning task queue.
Eclipse has a really interesting system--I don't know why so few people seem to know about it.
It's tied in with their to-do list. It gives you the ability to enter bugs with as much or as little info as you like. You can tie it to versioning or an external bug tracker if you like. It's a decent bug tracker in itself.
The real trick is how it works with your source code.
Before you begin work you select a bug from the list. All the time you're coding, it tracks what files you are editing. It can close old tabs for you, and will also highlight areas of the source tree that you have modified a lot.
The nice thing is, you can go back to any bug you've edited an you will get your "Environment" back. Not only all your notes and stuff, but the same tabs will open up and the same sections of code in the navigator will be highlighted.
Also eclipse works with virtually any language, it's not just restricted to Java...
let me put in a good word for ditz - it's a bit bare-bones, but it has the invaluable feature that bugs are checked into your repository. it's also very easy to use once you get used to its way of doing things
You can use fogbugz for free if you're a one man team.
It's super easy to use and quick to learn.
They made it so that bugs are really easy to enter, no mandatory fields.
I'm the author of BugTracker.NET mentioned in another post. If I were looking for a tracker for JUST ONE PERSON with MINIMUM hassle, I'd use FogBugz, because it's hosted. No installation, no need to worry about backups.
But, what are you doing about version control? Don't you have to worry about that too, and backing that up? If so, consider something like Unfuddle or CVSDude where you can get BOTH Subversion and Trac, or Subversion and Fogbugz.
I use Mantis at home and I'm happy with it. It can be a pain in the arse to get it working so you can choose to download a free and ready-made VM installation. Cannot be easier than that,
Maybe a spreadsheet would be the next logical step? I know it sounds really un-sexy, but if you're the only user, you don't have to worry much about others mucking it up, and it adds a few basic features over a text file like sorting. Then if you later need to graduate to something RDBMS-backed, you would likely have a feasible import path. I just know that for me, when working by myself, I don't tend to get around to putting bugs in anything that requires more care and feeding than that (of course when working with others the collaborative needs make a more defined repository a requirement, but that's a different story).
EDIT: After noting the availability of free, hosted access to FogBugz, I'm re-thinking the bar for care and feeding...
RT from BestPractical is great.
I also get a lot of mileage out of just keeping a list of items in a text file with vi, if I can express them all in one line. This is usually for many small todo items on a single component or task.
I've tried bugtracker.net and even though it's a little bit rough on the edges, it's free and was built with ASP.NET:
http://sourceforge.net/project/showfiles.php?group_id=66812
Are you using a source control repository as well? If not, you really should, even though you're only a one-man team.
My personal preference is to use a VMWare Virutal Application (free) that offers no-hassle setup gives you access to both Trac and Subversion. You can find many different virual appliances through searching. Here is one example of getting a Trac/SVN virtual appliance up and running:
http://www.rungeek.com/blog/archives/how-to-setup-svn-and-trac-with-a-virtual-appliance/
Trac is an excellent project management tool that sports a bug tracker, wiki, and integrated source control management. It's adaptable to your needs, and fits me very well personally.
I use bugzilla for this purpose. Plus for me was that it has integration with Eclipse (precisely with Mylyn). FogBuzz has it to but AFAIK it is nonfree.
Plus it sits on my laptop so I can code and add/remove bugs when offline (it was biggest disadvantage of hosted solutions for me)
Installation was not a problem in Ubuntu (and any debian-based distro I suppose).
I dig ELOG in those cases, it's more of a personal blog, but it's easy to handle and install, the data is local on your computer and you can search all entries via fulltext. Always sufficed for me.
If you have a Windows box with IIS and MSSQL (including SQL Server Express), you should look at Bugtracker.net. It is free and open source (you get the source code), and it is extensible.
Even if you are a one man shop, having a free bug tracking system with this much power will allow you to grow over time, because it is fairly easy to add future users into the system.
You can also customize it for the look of your organization, business or product.
Ontime 2008 by Axosoft is free for a single user licence. It's industrial strength and will give you alot more that just bug tracking!
http://www.axosoft.com
Jira which now has free personal licenses.
I am using leo for this purpose. To be more specific, its cleo plugin.
Of course you might need to spend some time to get used to leo, but it will pay off.
A flat text file is just a list, an Excel spreadsheet is a two-dimensional list.
leo lets you keep the data in a tree! And it also has clones.