|
If you want to stick with Microsoft, let me make these suggestions to look into:
For Normal Windows App Dev: C# and the Windows Presentation Foundation (WPF)
For Windows Store/Mobile/Cortana App Dev: C# and Windows Universal
For Web App Dev: C# and MVC/ASP.Net
The Windows Universal App platform is still pretty new so the developer base reamains relatively small. It also seems to picking up a growing number of detractors in the development community.
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
If you don't mind spending a little money, get a sub to Pluralsight. They have huge quantities of high-quality C# and .net training. You could even just sign up for one month ($30) and drink from the firehose for 10 hours a day if you're of a mind to. 
|
|
|
|
|
Plus 1 for Pluralsight. Best technical training out there.
Eric
|
|
|
|
|
Well, from what you wrote, why not start with the more esoteric stuff in C# - lambda expressions, LINQ, reflection, domains, anonymous methods, runtime code generation, IL, C# 6.0 features, etc.
That way, if you learn the advanced stuff first, your C# code won't look like VB6 code  Then again, your code might not look like average C# either, but I'm guessing you're already pretty comfortable with the boring stuff. 
Some good stuff (and boring stuff) here: http://csharp.2000things.com/
(Had to wait to post this for CP issue to be resolved, haha)
Marc
|
|
|
|
|
Foothill and Marc are both right. Go directly to c# the learning curve is fairly mild and it should break you of the old habits (it did for me).
I would first make a decision as to where you want to work, desktop LOB, web or hybrids. The UI tech it very different. You already have the database stuff, get to know the service side, WCF or web API both fairly straight forward. The target your UI tech.
Personally I went to desktop LOB, but then I got lucky and found a company that valued my experience and gave me a free reign on the tech I could use. Over 15 years I went from VB6 to VB.net in winforms to Silverlight and have moved to WPF where I am very comfortable.
To me the current web stack is a f***ing nightmare and I'm thankful I might be able to retire before it become a requirement.
Just read this[^], avoid EF like the plague, you know how to write a DAL you will be better served using your own.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I very much would like to stay in the Desktop LOB field. It is what I know and understand, in so much as I am good at taking a vague idea from a client and turning it into a stable piece of software that does what they want, or at I was. I love working with SQL Server and could prob make my living as a DB Admin, but I want to get back to creating. Anyway, thanks for the advice and answers so far. I am going to be looking into the books and training links provided so far.
I am kinda wondering if maybe I am overthinking this. Is C#, WPF, a DAL and SQL Server a valid collection of, and I am not sure of the term here, technologies/tools/platforms/frameworks to create a modern desktop application? Is that not leaving to many of the buzzwords I read every day, and mostly don't understand, on the table?
Also, I found the comment to stay away from EF very interesting. I created my own DAL, and wrote a program to generate the code for me from the database schema, in 1998. I have used it in every data accessing program I have created since that time. I would love to update it again and continue to use it, because I know it works. Do modern programmers do that? How important, I wonder, is knowing EF to finding a job in this day and age?
modified 11-Mar-16 23:41pm.
|
|
|
|
|
I started out with VB3 all the way up to VB.NET. Got me a VB5, VB6, VB.NET MCSD with that last on on .NET 1.1 in 2003. Lots of SQL. Similar development story to yours.
In 2007 I moved over to C# exclusively. Previously had code-generated DAL. I went on a mission to improve my development skills and ditched all the code-generation. Probably can still do some code-generation although I don't churn out so much DAL code anymore 
I got stuck into domain-driven design and with find that it really does address proper code and strategic structure. It is *very* difficult to find folks applying domain-driven design and even less doing it correctly. U also ventured into the service bus / messaging space.
My opinion is that web-development is probably going to be the way to go. Once browsers are all up-to-scratch some native mobile apps could possibly be web-based. Always an issue accessing local resources though. I started reading a WPF book years ago and quickly decided that this, along with its second-class citizen sister Silverlight, are going to have a tough time breaking into the mainstream.
What I would regard as my ideal stack / approach would be:
- domain-driven design
- No ORM
- event-sourcing
- service bus
- web-api / rest
- web-based front-end using some MV* technology such as CanJS. I have used Ember and *it* was painful.
I have created some open-source software during this journey:
- service bus: shuttle-esb documentation[^]
- samples: https://github.com/Shuttle/shuttle-esb-samples
- data access: GitHub - Shuttle/shuttle-core-data: Provides a very thin abstraction over ADO.NET.[^]
Hope that helps.
|
|
|
|
|
I, too, am maintaining legacy code in VB 6 for LOB apps.
I have looked @ C#+WPF and have come to the realization that LOB apps don't lend themselves to objectification to the degree required by C#
The other, huge, issue is printing, a task that all the LOB apps I've worked on the last 30 years really need to do.
C# just doesn't have the tools that VB6 does, especially formatting, string placement and printer control.
It also doesn't seem to support all the file access methods of VB6.
And it also doesn't support control arrays!!!
There is a VB6 library (namespace) that comes with VS that allows you to call the VB6 functions from VB.NET, including the printing and file access. So VB in VS might work well for you (if you don't mind the heaviest load of keyboarding I have ever seen - surpassing COBOL by a mile.)
I need to add parenthetically that I generally avoid packaged libraries because I have been badly burned by them. As a result I "roll my own" printing routines. Also, c# seems to rely heavily on 3rd party libraries which is another count against it IMO.
Murray
|
|
|
|
|
You're describing my history, with two differences: I didn't let that much time pass before I made the change, and I never even looked at VB.NET, I went straight to C#, thinking that a different language would help me break with VB6 nastier habits.
I was wrong. Just like you, I was writing good procedural (VB6) code in C#: I didn't understand, so I didn't use OOP, lambdas etc. My advice is that first and foremost, train yourself in OOP thinking. Learn patterns, and apply them. When you have a good understanding of these basic foundations of programming that we could happily ignore in VB6, then you can learn C#, WPF, ASP.NET or whatever else you choose.
|
|
|
|
|
Same here, VB3 to VB6, with other technologies (C, C++, Object/1, database, etc.) interspersed. I shifted to VB.NET for a couple of years around 2002, and then onto C#.
I did some personal research recently, and C# (IMO) is a good choice. Different sites measure in different ways, but all agree that C# has good market share, e.g., there are many jobs available. Microsoft supports it so it's not likely to go away any time soon. Which platform? I suggest you get a primer on all of them, it will help you make an informed choice. Then delve deeper into your chosen one.
Start with Windows Forms programming -- it's the most familiar and you'll make an easier transition. But after that, I agree with the folks that recommended web programming. If you want to be more marketable, that is key.
That said, it sounds like the real problem is getting a handle on OO programming. THAT is the crux.
When I moved to VB4 I shifted into OO mode, er, well, as much as VB allowed. It was good training, thinking in terms of encapsulation. The shift into VB.NET and then C# wasn't that difficult for me, more a matter of training myself to take the lessons farther.
Vaughn, I suggest you get a decent C# book. I like the SAMS series -- I used several of them over the years in different technologies and they are good, basic training that cover a lot of bases in an organized fashion. The lessons are practical and you can see daily improvement. [I also have WROX Professional C# 2008, but I found that one useful as a reference, not as a teaching aid.]
I found the following one on Amazon, not sure it's the most recent, it was published in 2012. Check publication dates -- the original C# book from 2002 is still available, you don't want that one.
Sams Teach Yourself C# 5.0 in 24 Hours: Scott J. Dorman: 9780672336843: Amazon.com: Books[^]
Don't try to learn everything at once. You will overwhelm yourself and kill your own self confidence. Start with Forms programming, then expand your horizons.
Good luck and perseverance!
|
|
|
|
|
CMPerez wrote: My advice is that first and foremost, train yourself in OOP thinking. Learn patterns, and apply them.
Pretty sure, that hits the nail on the head. Now I just need to figure out how to go about learning to think like that.
|
|
|
|
|
I have some bad news for you. This thread has been talking about you studying things, which is definitely needed, but its going to be hard to master without a job doing it, and so on.. Its kind of like learning a foreign language - it's far easier to learn when you are "In Country".
So what to do about this chicken and egg problem? The first thing you have to hurdle, is the job application, and the interview. Your CV will be scanned for mere seconds, and they are looking for key words. The CV gets the interview, gets the job. So I would add those key words (ASP.NET MVC architecture), (You wouldn't be the first person to do this). But be honest about your skill sets in the interview. In the mean time create an app of your own to learn the basics. Use a book, use a template from Microsoft, whatever you can do to become conversant. Using the ASP.NET MVC architecture.
Then, focus on common interview questions, and bone up for the interview. Do not try to sell yourself as an expert, be honest about your skill level. The truth is, experience on one ASP.NET Project doesn't make you an expert in another. Everyone has to learn on a new job. Its going to be hard, maybe impossible. (You didn't mention if you had a job currently) If you do, you should stay late, come in early, carve out some time to "learn on the job". If you don't, then you have all the time in the world. Focus on answering the interview questions, divide your time between actual coding ,and plain old studying. REST, WEB API, all the things you should at least be able to convey understanding. Look for interview questions, that exist on this site as a template for study.
Once you get the job, you need to put in extra hours to play catch up. Do everything you can to understand how the existing code works. Network with team members for help, but be careful not to ask questions the google can answer, rather ask specific questions about where to get the code from the repo, things that are unique to that job. Lastly - don't feel too bad about yourself, this happens to lots of people who stay at a place (maybe too long). You wind up dragging code around for years, stuck in a vertical. Employers will even hire new folks, rather than help existing folks along with this constant learning curve.
Very Last thing: Get started today. Don't waste another minute.
Where there's smoke, there's a Blue Screen of death.
|
|
|
|
|
Very practical advice. Up-voted.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
Great advice here. Having been in a similar situation and wanting to move on to newer technologies one of the things I did was to find a job that had a mix of the old and new. Then while working (and hopefully upgrading) the old I had access to the code written in the new technologies to learn from.
|
|
|
|
|
The web development field is saturated with posers.
I specialize in desktop, back-end and web services; leaving the rest to those that don't know the difference between XML, XAML and HTML. (And there are a lot ... I also avoid IOS, Android unless it's using some C# cross-development tool).
My tools of choice are C#, WPF, SQL Server, WCF and EF (and anybody that says to avoid EF does not know what they are talking about; or they like bit-fiddling). I'm also not a slave to MVVM; developing highly interactive custom desktop apps that do not necessarily benefit from a "one size" mentality.
The web development arena reminds me of PC development in the 90's; lots of 3rd party shite that was needed to complete one's toolkit. With the MS stack I referred to, I can pretty well do anything.
(I was "outsourced").
I "remade" myself by taking on freelancer jobs that would stretch my new found knowledge (C# walkthroughs and "how-to"): it was like getting paid while learning. (Just don't blow the project).
I continue to freelance using my tools of choice, with the occasional 3rd party graphics library. My current gig is running into it's 3rd year with no definite end in sight .... Desktop (kiosk) development.
Every freelance project I worked on always required me to learn something new; even when the project on the surface seems trivial. You can add it to your "experiences".
Every time someone comes here asking for "the codez", they are told to "go to a freelancer site". As a "seller", these sites are worth checking out and experiencing the current state of "software development" (LOLZ). Check out the forums (beefs and bouquets). Once you figure out how to play it, it can be fun and profitable.
|
|
|
|
|
I'm pretty much done with my first complete MVC app. It allows the user to take a survey.
It's not nearly as interesting as the WPF desktop application that allows you to construct the survey, and I hated every minute of the development time.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Can we see it?
If it's not broken, fix it until it is
|
|
|
|
|
He works for the government. He could show you, but then he'd have to kill you.
|
|
|
|
|
Oh right, I forgot.
Redacted!
If it's not broken, fix it until it is
|
|
|
|
|
I think it's the paperwork involved in seeing it that would kill you.
cheers
Chris Maunder
|
|
|
|
|
Not quite, you have to sign something agreeing to kill yourself. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I know the feeling. The Razor view engine has grown on me but the need to write controller actions and views to handle all the separate things that can happen to a 'Model' gets old pretty quick. And don't get me started on the Entity Framework. I started out in the database world before graduating to application programming and the things that the Entity Framework does makes my eyes bleed.
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
OK, I know it's Fox News, and you can't trust anything they say.
But...Fire on the Sun[^]
O...kay...so now we know...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
