Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm an ambitious millennial who has chosen to self-teach myself a few things that could obtain me success. One of them is software development - with two possible avenues for success - create my own website, and be my own boss. The other is - to get certified through Microsoft in my area of expertise and work for a company. My area of expertise? Well, I'll try to be quick here, I started learning ASP a long time ago, and then I learned ASP.NET WebForms, and then, most recently, I've learned and have gotten a pretty good grasp of ASP.NET MVC. So, my issue is this:
I've had my eye on doing this for a while now, and I noticed how Microsoft modifies its Exam's every year, so, every so often, I check on the MCSD testing page to see what's currently offered. At the time of this writing, what I'm interested in is becoming what's now, in December 2016, known as a Microsoft Certified Solutions Developer for Web Applications (the MCSD: Web Applications certification branch), but I just found out the certification expires on March, 31 2017.
The exact page that made me feel alarmed on the topic is - https://www.microsoft.com/en-ca/learning/mcsd-web-apps-certification.aspx - and, the exact quote was "Note This certification will retire on March 31, 2017. When the certification retires, all individuals whose transcripts list this certification as active on or after September 26, 2016, will retain the active status. Find out about the replacement certification, MCSD: App Builder."
As I said, I'm ambitious, and have a few avenues I can pursue. Although, as I said, I've been interested in getting this certification for some time now, but, it's just that I've been busy doing many things, and I'm unsure if I can complete the exam by that date, and the new replacement certification branch (MCSD: App Builder) doesn't make sense to me, I want to develop with C# and MVC, and I don't want to have anything to do with Azure - which is what that new replacement branch is focused on - while the current branch that's available till March, 31 2017 - has a specific exam for MVC developers (Developing ASP.NET MVC Web Applications). I don't understand why Microsoft feels this change is necessary, this is alienating developers like myself. I don't know what to do, I wish there was something I am unaware of here, and there still will be some kind of exam offered specifically for MVC (I mean, since MVC was introduced, there's been an exam specifically for it - and now, they want to get rid of the focus on it altogether when it comes to certification? Maybe it's because Microsoft just made ASP.NET and MVC (under the new "Core" Framework) to be open source...)
If anybody here has any reassuring information for me, or some kind of information that'd help in some way pertaining to this, I would really appreciate it.
I have both MSCD: Web Apps and MSCD: App Builder.
Web apps is based around the older .NET 4.5 and 4.6 framework of doing things, where as App Builder is geared towards the .NET Core and .NET Standard upcomings.
I believe you only need to do 2 exams for App Builder itself, but you need to hold a certification lower then it (which is 1 exam), instead of the 3 exams for the Web apps cert.
Basically they have just moved the structure around a little bit to better adapt to their newer technologies coming out and to make it a little easier for people to get certifications.
Technically the MCSD: Web applications certification is only valid for 2 years anyways once you've achieved it.
The current MSCD: Web apps exam has been around for about 3 years or so, expect that they will be making changes like this every 3-5 years.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Having experience in java (awt and swing) and also in html and javascript I have moved and in my new country found a job in a consulting company as a developer.
I also had experience doing some stuff in c#, but never touched the GUI part.
I have seen that the most of our clients are using .net, so I have decided to update my knowledge in .net and also learn about the GUIs while I have no assigned client.
But my problem is that for the GUI part I can see there is:
Windows forms
Windows Presentation Foundation(WPF)
WinRT
Universal Windows Platform (UWP)
asp.net
I understand all of those are not the same, some are compatible with each other (winform and WPF) and others are not. Syntaxis is different and also the elements available to create the GUI. I have searched and even coded some basic examples and found out even the way to program (events vs databinding) changes a lot. I also read several discussions about the pros and cons for each one.
Now, taking into account my context (big company, not a startup) which one of the above technologies should I focus into? and by this I mean: Which one has a bigger marketshare in 2016 or will have more action in the near future (I know it's impossibe to predict technology in 10 years but lets say 2-3 years). Is there any statistics or any official position from Microsoft about wich one will be the standard?
Thank you for taking the time to answer.
Edit: For those who didn't understand and are down voting my question saying is opinion based: I am not asking for which one you prefer. I am asking is there's some statistics or an official position from Microsoft about this.
Some of you say you cannot compare different technologies because it is like to compare programming languages. This has been done, because I am not asking to compare the technology itself but the marketshare. If you want to compare javascript with .net and abap MARKETSHARE you can use the tiobe index.
If you dont know the answer simply do not say anything, but not pretend people cannot ask things you don't know about.
Edit2: Finally I found what I was looking for.
For desktop application
42% use Windows Forms, 46% WPF and 8% UWP
More data available at http://www.telerik.com/campaigns/devcraft/net-developer-report-for-2016
WinForms is very old technology, so better choose something new.
If talk about vacancies now, I think that ASP.Net is leader. What would be in future - have no idea. Azure? ASP.Net Core?
WinRT (Windows Store 8.1 Apps) and UWP are have much in common but not extermely popular yet. Advantage is that you can write your apps already for desktop, phone, XBox, raspberry pi and more devices.
WinRT Windows 8 Apps are depricated.
WPF is nice. Better start learn .Net Core Apps (they are crossplatform)
Xamarin crossplatform apps are also popular now. You can write C# apps for Windows, iOs and Android.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am planning to develop a cross platform standalone app to support windows and Linux. TideSDK is my personal choice to go with. But, I have been actively following tideSDK(tidekit) for last 6 months and does not see anything about their product launch.
Can we expect tidekit to launch by near future?? or should we approach some other tool.
Just to be clear - you're not expecting to provide a version of the platform for us to use in 2014, but you're committing to releasing a plan in 2014 in which you will let us know when you plan to release the platform (which could be 2015, 2016, 2017, ...)?
Just trying to get my development options in place for 2015 and I'd like to know if you plan on having something available in 2015 that can be used for development, and if so, in which half of the year?
TideKit.com and TideKit have been discontinued. (This tidekit response mail)
TideKit was software for developing apps for all platforms simultaneously with a single base of code written in JavaScript.
The scope and complexity of the product made it difficult to assemble the platform all at once. This stemmed from a holistic approach to app development for all platforms. While creating a platform for JavaScript developers, much of the core engineering is in a variety of lower level languages that affect the speed of development. We considered delivering parts of our platform as we reached milestones, but this was not suitable for the start of trials.
We were widely criticized for not revealing our technical innovation in advance of our release. In a competitive environment, revealing advantages as you go can also mean assimilation as you go. We had already witnessed how quickly our technical advantages could be assimilated by competitors to our open source TideSDK product. Therefore, we held back with a view of delaying the duplication of features by competitors, increasing our technical barriers and working to protect our IP and business case until we felt we were ready.
In a startup, we talk about a Minimum Viable Product (MVP). In our case, our minimum viable product was much larger and more difficult to achieve. In total, approximately three years of research and development was committed with multiple developers working greater than full time hours. A factor that extended the development was an expansion of scope that aimed to lower friction in the app development process.
In Feb 2014, we created a system to queue developers with reservation system for the earliest possible access to TideKit. Our goal was to provide an early trial when it became available. Since the development itself was complex, we could not provide a date when ticket holders could start the trial process – but it would be following our betas, then moving forward as we scaled the platform.
We were clear with our language on the site concerning reservations. As a result, we expected little confusion about what was being purchased, our expectations of timing to market, or the terms of purchase for a reservation ticket. Purchasers were not paying for our product at this point, but for their position in a queue for a trial of our new technology. We also included a refund policy to ensure the terms of purchase for your ticket were available. The wait has been long, but not nearly as long as other difficult engineering challenges including Myo that pre-sold their product and were also delayed before successfully rolling out.
Throughout the development cycle we provided updates of our status via posts roadmap page, email to our ticket holders and communications on our social channels. We did our best as a team to open ourselves to questions and maintain a social presence.
At the end of May 2015, we communicated our strategy to execute a series of focused betas that would have seen the platform revealed publicly and incrementally. We were at a stage that parts of the platform needed developer feedback as we rolled these out consecutively.
In the days preparing for our first public beta, we recognized the extent to which our brand had been poisoned by our timing to market. A campaign of negativity that had begun several months earlier with followers and ticket holders had taken its toll on our team, brand, and business.
We believed the beta releases would soon bring an end to the negative talk. On July 8 and 9 we faced further eruptions on social media that reached the tipping point. With the discussion no longer about the product nor its future, this was far more serious.
We failed to bring the product quickly enough for you. As a result, we came to the serious decision to discontinue TideKit and dissolve our company.
We wish to thank everyone involved that worked on the product and with our team. This includes businesses, entrepreneurs and supporters of our vision for app development.
Your TideKit Team
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I was wondering if anyone has performed a migration from PowerBuilder to ASP.NET? Is this going to be a complete rewrite, is there a list of best practices for performing this type of migration? I personally have never worked with PowerBuilder and any guidance and or suggestions would be appreciated.
If you have never worked with PowerBuilder but have been tasked with migrating a decently sized application written in it, I would highly suggest you do the following:
Schedule a meeting with the project owners.
Show up with a blank notebook and pencil / pen.
The first question should be: "What do you want the new system to do?"
Go from there...
Migrating a decently sized system to another language is so full of pitfalls a lot of times it's better to wipe the slate and start over... Unless the team is fluent in BOTH languages. Of course, starting over has it's own drawbacks as well. I hope they are prepared to spend a lot of time and money.;)
I'd suggest
starting with my previous post on converting PowerBuilder to .NET,
subtract the DataWindow.NET suggestion (it's been discontinued in favour of control generation from PB.NET 12.5, which is a little steep in price for custom controls),
then add my opinion that client-server UI design (you don't say whether it's C/S or not, but I'll make that assumption) has different best practices than web design, so a lot of the functionality in the PowerBuilder app should be redesigned for the new platform. (I suggest this to PowerBuilder users even when they're moving to PowerBuilder's WebForms functionality.)
I've seen browsers time out because the developer was loading too many items into a dropdown for a web browser, and while I wouldn't call it optimal for client-server, it didn't bring the UI to a screeching halt.
If you're dead set on this, I'd use your PowerBuilder app as a business definition document, and start budgeting to build from the ground up.
Good luck,
Terry.
I have converted the powerbuilder 12.1 source into powerbuilder.net it gives you all functionality in web environment but right now its performance is very slow.
I also did a huge application migration from PB 12.1 to PB.NET.
It wasn't easy. I did a heavy use of SetRedraw, and that function is not more available in .NET.
After fixing a lot of migrated code, I noticed very low performances compared to PB classic.
PB .NET Ide is slower than Visual Studio one, and it allows you to mix PB code with .Net framework code.
After a forecasting cost review, we decided to rewrite a new form application with Visual Studio .NET and it revealed the right choice.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
a couple of days ago I had this idea, why not implementing asp-classic as another language in .net...
it would have helped lots of people to migrate to the new platform...
I mean there's IronRuby, IronPython, etc...
It sounded to me like a great idea... but, come on, I'm no genius, there must be some reason why they haven't done so...
I'm just curious about it...
Because Microsoft has given up on backwards compatibility of their API's. I guess they figured that using the maintenance cost for new development was a better investment.
Sometimes I agree, sometimes I disagree with their new view...
Now so you don't think its just me projecting my thought on microsoft here you have some references:
Joel's an article about it
The first big win was making Visual Basic.NET not backwards-compatible with VB 6.0. This was literally the first time in living memory that when you bought an upgrade to a Microsoft product, your old data (i.e. the code you had written in VB6) could not be imported perfectly and silently. It was the first time a Microsoft upgrade did not respect the work that users did using the previous version of a product.
...
With this major victory under their belts, the MSDN Magazine Camp took over. Suddenly it was OK to change things. IIS 6.0 came out with a different threading model that broke some old applications. I was shocked to discover that our customers with Windows Server 2003 were having trouble running FogBugz. Then .NET 1.1 was not perfectly backwards compatible with 1.0. And now that the cat was out of the bag, the OS team got into the spirit and decided that instead of adding features to the Windows API, they were going to completely replace it.
Primarily because asp-classis is not a langauge. Its a very small framework of COM objects.
The builtin languages for use in ASP are VBScript and Javascript. I can't see why anyone would want to use "VBScript.NET" and "JScript.NET" does exist although its a bit of dogs dinner.
You can take a ASPX page with VB.NET can code isn ASPEsq manner if you like.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Having not done ASP.NET since v1.1, and now blitzing through the Wrox Pro ASP.NET v3.5 book, what other resources are available to get me developing enterprise ASP.NET apps the fastest?
I've been developing in DotNet since Beta and have been doing Winform & middle-layer architecture/design/dev for 3.5 years now (as this has been my client's desires). But I'm finding my falling behind has hurt me concerning a new client. :(
I'd appreciate any advice on moving forward as fast as possible. I'm looking for anything RAD related or even just great books on the subject that you recommend. Right now, I'm having fun consuming the Wrox book though. Thanx much!
I'd start with the QuickStart tutorials. That'll get you into the code, get you some exposure to the programming, architecture, controls, data access, and so on. You can also watch videos of how to accomplish various tasks in ASP.NET at the ASP.NET web site.
Assuming you already have substantial VB.NET or C# experience, you should get deep into ASP.NET fairly quickly.
Take a look to the ASP.NET Dynamic Data Scaffolding Framework (included in the .NET Framework 3.5 SP1), it allows you to build really quickly data driven web applications. Here you can find more good videos and resources about this RAD feature.
Not that easy, since "enterprise" is a word that can encompass lots of things. First off, I would suggest just getting to know which new frameworks are available, both out-of-the-box and not. And there's been a lot of those since .NET 1.1.
WCF, for example. Dynamic Data, as mentioned in another comment. ASP.NET MVC. LINQ, ADO.NET EF, WF.
I'm not suggesting you learn all of them, at least not all at once. Rather, be at least familiar with what they are and what they bring to the table. Browse through the base class library reference and familiarize yourself with the available namespaces. This will help you know what's there and what you will have to write. Try your hand at the bits that interest you.
After you're a bit more well-versed with the .NET framework, it's time to take a look at the other stuff you'll need for enterprise development. Frameworks such as CSLA and NHibernate. Testing stuff like TypeMock. As before just knowing what's out there, even without knowing the details, can help quite a lot.
Write code. Nothing quite like writing code if you want to learn quickly. Choose one of the apps you wrote back in the 1.1 days, and try to write a shorter, cleaner and/or more maintainable version with the new tools at your disposal.
And don't forget to have fun. If you're not enjoying what you're doing, you won't really be learning much. Good luck!
You probably shouldn't mix "enterprise" with "rad" as the two generally have extreme connotations on opposite ends of the spectrum.
Enterprise typically draws up ideas of, large, line-of-business applications, large complexity, large configuration, (and some would probably relate to pain, nightmares, etc..)
RAD typically refers to the drag & drop garbage that you see in awesome conference demos, but then you go back home and try to build and maintain and app built with dragging and dropping controls & data acccess components on your UI and you quickly see that it breaks down.
Pick a good balance of tools & techniques that make you productive, but at the same time don't sacrifice maintainability.
You'll find no shortage of opinions of "how you should work" here on Stack Overflow, but the best advice I can give you is to be pragmatic, read as much as you can stand, and code-code-code. I code on the bus, at home, at work, on a plane, in a hotel room, etc. Try out different tools/frameworks, see what their communities say, try building a simple todo-list app, etc. Get your feel for what's out there.
You're on the right path by reaching out to the community.