I was using a CASE called MAGIC for a system I'm developing, I've never used this kind of tool before and at first sight I liked, a month later I had a lot of the application generated, I felt very productive and ... I would say ... satisfied.
In some way a felt uncomfortable, cause, there is no code and everything I was used to, but in the other hand I could speed up my developing. The fact is that eventually I returned to use C# because I find it more flexible to develop, I can make unit testing, use CVS, I have access to more resources and basically I had "all the control". I felt that this tool didn't give me confidence and I thought that later in the project I could not manage it due to its forced established rules of development. And also a lot of things like sending emails, using my own controls, and other things had their complication, it seemed that at some point it was not going to be as easy as initially I thought and as initially the product claims. This reminds me a very nice article called "No Silver Bullet".
This CASE had its advantages but on the other hand it doesn't have resources you can consult and actually the license and certification are very expensive. For me another dissapointing thing is that because of its simplistic approach for development I felt scared on first hand cause of my unexperience on these kind of tools and second cause I thought that if I continued using it maybe it would have turned to be a complex monster that I could not manage later in the project.
I think it's good to use these kind of solutions to speed up things but I wonder, why aren't these programs as popular as VS.Net, J2EE, Ruby, Python, etc. if they claim to enhance productivity better than the tools I've pointed?
We use a CASE tool at my current company for code generation and we are trying to move away from it.
The benefits that it brings - a graphical representation of the code making components 'easier' to pick up for new developers - are outweighed by the disadvantges in my opinion.
Those main disadvantages are:
We cannot do automatic merges, making it close to impossible for parallel development on one component.
Developers get dependant on the tool and 'forget' how to handcode.
Just a couple questions for you:
How much productivity do you gain compared to the control that you use?
How testable and reliant is the code you create?
How well can you implement a new pattern into your design?
I can't imagine that there is a CASE out there that I could write a test first and then use a CASE to generate the code I need. I'd rather stick to resharper which can easily do my mundane tasks and retain full control of my code.
The project I'm on originally went w/ the Oracle Development Suite to put together a web application.
Over time (5+ years), customer requirements became more complex than originally anticipated, and the screens were not easily maintainable. So, the team informally decided to start doing custom (hand coded) screens in web PL/SQL, instead of generating them using the Oracle Development Suite CASE tools (Oracle Designer).
The Oracle Report Builder component of the Development Suite is still being used by the team, as it seems to "get the job done" in a timely fashion. In general, the developers using the Report Builder tool are not very comfortable coding.
In this case, it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background.
Unfortunaly the Magic tool doesn't generates code and also it can't implement a design pattern. I don't have control over the code cause as i stated before it doesn't have code to modify. Te bottom line is that it can speed up productivity in some way but it has the impossibility to user CVS, patterns also and I can't control all the details.
I agree with gary when he says "it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background" but also I can't agree more with Klelky;
Those main disadvantages are:
1. We cannot do automatic merges, making it close to impossible for parallel development on one component.
2.Developers get dependant on the tool and 'forget' how to handcode.
Thanks
Related
Our company builds several (Java) applications that loosely communicate with eachother via web services, remote EJB and occasionally via shared data in a DB.
Each of those applications are build and maintained by their own teams. 1 or 2 persons for the smaller apps, and almost 10 for the largest one. The total amount of developers is approximately 25 FTE.
One problem we're facing is that there are some big egos among the teams. Historically the team of the largest app has set up a code convention and general guide lines. For instance our IDE is Netbeans, we use Hg for SCM, build with Ant and emphasize to first use as much from Java EE as possible, if that doesn't suffice use an external library and only resort to writing something yourself as a last resort. Writing things like yet another logging framework, orm, cms or web framework is pretty much not allowed following these guide lines.
Now some of the smaller teams go against this and start using Eclipse, Git and Maven and have an approach of writing as much as possible themselves and only look at existing things if time is short or they 'just don't feel like writing it themselves'. Where the main team uses log4j, one of the smaller teams just started writing their own logging framework.
There have been talks going on about all teams adhering to the same standards, but these have been 'troublesome' at best.
Now the big question I'd like to ask: does it actually matter that different teams do things differently? As long as each seperate app implements its requirements and provides the agreed upon interfaces, should we really force everyone to use Hg, Ant, the same code conventions, etc etc?
There is not much harm in letting each team use the technologies that work best for them. In fact if you restrict teams to the "standard" way of doing things you'll stifle innovation and have bad morale.
But you don't want things to diverge too much. There a few things you can do to prevent libraries and tools getting out of hand. The first thing is to have regular rotation of each member through the teams to cross pollinate ideas. In this way the best ideas will spread through the teams.
You can also enforce a "rule of 3", which simply says it is ok to introduce a second library, tool, logging approach, whatever. But as soon as you want to introduce a 3rd one, you have to remove one of the first two. In other words it is ok to have 2 competing logging frameworks but if there are 3 logging frameworks, choose one to kill.
A 3rd idea is to let developers run regular presentations to the entire developer group to demonstrate the pros and cons of each idea or approach. Encourage lots of discussion and constructive criticism. The purpose is to try many things and let everyone find the best way as a group.
Finally, Management 3.0 talks a lot more in depth about how teams make decisions. Well worth the read.
Does data binding fit in a 3 layered architecture? Is dropping a grid-view on a web form and binding it to a LinkDataSource or SQLDataSource considered bad? The way I see it, that's the Presentation Layer talking to the Data Access Layer. I once heard a "professional developer" say never ever do this, so what's the alternative if you shouldn't?
The way you are doing is ok if it is a small project, but if you want your app. to have flexibility to support Windows/ Web in future then you must use Layers.
Please follow this link http://www.dotnetspider.com/resources/1566-n-Tier-Architecture-Asp.aspx
You should have a middle tier between Presentation and Data Access layers, the middle tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.
The main task of Business layer is business validation and business workflow.
When you build your business logic components into an SDK, you are effectively disconnecting it from your Web application, and any input validation that it performs. Therefore, your business logic components are the last line of defense to make sure that only valid values make it into your database.
Databinding is, of course, necessary to effectively dispay data.
Tooling is great and can boost productivity. It is equally important to understand what the tooling is generating, even at a basic level, in order to be able to effectively utilize the generated code.
The reaction you describe seems a bit extreme. If a wizard can generate some code that works for ya, then use it. If you don't understand the generated code then that is the next priority; learn about what it is doing and why. In the meantime, you have a page that people can put eyes on regardless of how it got there.
I am a bit pragmatic when it comes to tools. You do what you have to do. But, if after [insert appropriate internship length] you are still using code gen and cannot customize or fix it then you (as in the royal you, not the you you) are being lazy or stupid or both. ;-)
OT:(almost) Never say never unless you want to lessen the impact of what you are trying to communicate.
my 2 pesos.
When you're doing a small project or a prototype, go with the LINQDataSource or SQLDataSource. However, the downsides of those data sources are serious enough for you to think hard if they are appropriate. If your doing a multi-layered or multi-tear architecture, they simply don't fit. But even if your architecture isn't that strict, you should ask yourself how big this application is going to be and how likely it is going to be that you will make changes to the system in the future. How much time it is going to take you when you want to make a change to the database?
I've seen projects were the developers used those data sources, because those were the constructs that were used in those nice ASP.NET video's. However, when the projects grown from prototypes to big production applications (yes, I’ve seen it happen, the prototype seemed good enough), the lack of compile time support (your queries are defined in markup!) made it very hard to do any change to the system.
When you need to make a change to the system, that will be the time that you’ll see that the cost of the change is a magnitude bigger than the time you saved by flattering your architecture.
I have been tasked with automating some of the paper forms in HR. This might turn into "automate all forms" eventually, so I want to approach this in a way which will be best for the long term and will be a good framework as this project grows.
The first things that come to mind were:
-InfoPath/SharePoint (We currently don't use SharePoint now, and wouldn't be an option for the next two years.)
-Workflow Foundation (I've looked into this and does not seem too attractive or appropriate)
Option I'm considering at this point:
-Custom ASP.NET (VB.NET) & SQL Server, which is what my team mostly writes their apps with.
-Leverage Infopath for creating the forms electronically. Wondering if there is a good approach to integrating this with a custom built ASP.NET app.
-Considering creating the app as an MVC web app.
My question is this:
-Are there other options I might want to consider?
-Are there any starter kits or VB.NET based open source projects there which would be a starting point or could be used as a good reference. Here I'm mostly concerned with the workflow processing.
-Any comnments from those who have gone down this path?
This is going to sound really dumb, but in my many years of helping companies automate paper form-based processes is to understand the process first. You will most likely find that no single person understands the whole thing. You will need to role-play the many paths thru the process to get your head around it. And once you present your findings, everyone will be shocked because they had no idea it was that complex. Use that as an opportunity to streamline.
Automating a broken process only makes it screw up faster and tell a lot of people.
As far as tools, my experience dates me but try to go with something with these properties:
EASY to change. You WILL be changing it. So don't hard-code anything.
Possible revision control - changes to a process may or may not affect documents already in route?
Visual workflow editing. Everyone wants this but they'll all ask you to drive it. Still, nice tools.
Not sure if this helps or not - but 80% of success in automating processes is not technology.
This is slightly off topic, but related - defect tracking systems generally have workflow engines/state. (In fact, I think Joel or some other FC employee posted something about using FB for managing the initial emails and resume process)
I second the other advice about modeling the workflow before doing any coding or technology choices. You will also want this to be flexible.
as n8owl reminded us, automating a mess yields an automated mess - which is not an improvement. Many paper-forms systems have evolved over decades and can be quite redundant and unruly. Some may view "messing with the forms" as a violation of their personal fiefdoms, so watch your back ;-)
model the workflow in terms of the forms used by whom in what roles for what purposes; this documents the current process as a baseline. Get estimates of how long each step takes, both in terms of man-hours and calendar time
understand the workflow in terms of the information gathered, generated, and transmitted
consolidate the information on the forms into a new set of forms for minimal workflow
be prepared to be told "This is the way we've always done it and we're not going to change", and to gently (a) validate their feelings, (b) explain how less work is more efficient, and (c) show concrete benefits [vs.the baseline from step 1]
soft-code when possible; use processing rules when possible; web services and html forms (esp. w/jquery) will go a long way if you have an intranet
beware of canned packages (including sharepoint) unless you are absolutely certain they encompass your organization's current and future needs
good luck!
--S
I detect here a general tone of caution with regards to a workflow based approach and must agree. Be advised about the caveats of most workflow technologies which sacrifice usability for flexibility.
I've been working in ASP.NET for several years now (since the 1.0 days!), but I've never been formally instructed. I'm fully capable of doing pretty much anything I want and I've built several production-level, data-driven sites, including one that does over a million in sales a year (according to the owner). But I'm starting to get the feeling that the holes in my knowlege are dragging my productivity down. I read a lot and try to learn wherever I can to try to stay up with all the new technologies, but sometimes I just don't get it, and I think it's because of my lack of formal training.
Does anyone have any ideas on the best way to fill in these gaps without having to rehash the fundamentals?
Thanks
1) Read the Code of popular Open Source Projects. There are a few that have some really good practices in place.
I recommend checking out BlogEngine.NET. Also if you're more ambitious, I'd suggest looking at the code for ASP.NET MVC 1.0.
2) Sometimes you need to "get back to the basics" when you've been working with a particular framework since a much earlier version. In this case, it can be really useful to pick up a book that covers some of the newer features.
Here's a good book that shows of some of the new features in C# 3.0:
C# 3.0 Design Patterns
3) It may seem odd, but reading up on other languages/platforms (such as Ruby on Rails) will help you in the way you design your classes and code by taking tips of the good and bad of different platforms and combining them.
4) Read some books on general best practices and development methodologies.
Some of these books I recommend are:
The Pragmatic Programmer: From Journeyman to Master
Practices of an Agile Developer: Working in the Real World
Code Complete: A Practical Handbook of Software Construction
I'm in the same boat; been a .Net developer for 6 years. While I do have a CS degree, I don't have any formal training in ASP.Net; I learn it on the job as projects come up.
I found the best way to figure out what to learn is to keep your eye on .Net developer blogs. Some I follow:
David Hayden http://www.davidhayden.com/blog.aspx
CodingHorror.com (you might be familiar with it ;-)
Scott Hanselman http://www.hanselman.com/blog/
Usually from reading their blogs, I pick up on what the latest .Net solutions that are out there and point me in the direction of new tech I should look into further.
Overall though, I can only give you the advice I give junior devs at my company; realize you can't possibly be expected to know everything but always be eager to learn. Good luck!
I can absolutely identify. I've been programming since 1997 and really don't have any formal training to speak of. With regards to ASP.NET, everything I've learned has been through open code (Community Server, BlogEngine.NET, the other ASP.NET Starter Kits), books, LearnVisualStudio.net, and constantly being thrown in the fire.
I have a MASSIVE inferiority complex as I'm always wondering "did I do this the smart way or the inexperienced way". All I know is that my customers are happy, the errors that occur are few and are fixed quickly, and I keep getting work.
Luckily I have a passion for my work and that's what drives me to keep improving (slow though it may be).
If you're a "people person" then I think user group meetings are a great resource. I'm a bit of an introvert and unless someone who's smart reaches across and shakes my hand, I pretty much rely on the speaker's presentation to teach me something new. Probably not the best way to go and also probably why I don't go that much.
But again, I would stress the open projects, especially Community Server.
Seek out people better than you and learn from them.
Take some classes or join a user group.
If you are looking at conferences, consider finding a local Code Camp. These conferences are often very low key, but have excellent information content. They involve local presenters and attendees so you can build up your contacts and a set of people you can run things past when you need help. In addition, you might want to find (or start) a local .NET group where you can learn together. These can be hard to get off the ground, but when done well can be an excellent source of community learning.
Look for interesting ways to break your established patters - even at a loss of productivity.
Otherwise, it sounds like you are already in a pretty good spot. You can deliver on current requirements and sound like you can pick up new tricks when needed.
Really, the best way to learn new techniques is to work on a different project - even if that means changing jobs. If you have relevant and continuous experience since 2001, you should be able to pick your projects.
I've been coding PHP on a current project and it's been an interesting break from webforms. If anything, I'm getting good perspective on both models and really looking forward to doing some work in MVC.
I'll probably get some -1's for this, but as a fellow ASP.NET developer I don't think you really need to learn ALL that the framework has to offer. The reason I say that is that over the years my LACK of knowledge of all the cute little conveniences of ASP.NET has caused me to write better performing and more robust web apps for Windows. Balanced design patterns (separation of concerns) WITHOUT OVERDOING IT will make more of a "better" ASP.NET web app than using all of the controls and tools that come with the framework.
Case in point is the ajax stuff you get with ASP.NET, and also data binding. Since ASP.NET was late in the game with Ajax, I started off with my own ajax wrapper (based on an early ajax book) and then moving to jQuery. My co-workers all swear by the UpdatePanels and 3rd party controls, and quite often the user experience ends up worse and more confusing than a regular post back (and then we have to inject javascript to make it perform better and more seemlessly). As far as data binding, I've yet to find a canned control (from Microsoft or any 3rd party) that handles 2-way binding better than the framework Rick Strahl came up with back in the 1.1 days. We built a framework on top of a paper and some base classes he released, and I've yet to see something that I think handles data binding any better in ASP.NET (well...besides WPF/Silverlight...those frameworks really nailed it IMO).
So, to me, the path to upgrading your ASP.NET skills is to come up with some good ways to separate your business logic into logical components in the cleanest possible way, and learn the hell out of C# and JavaScript (and/or a JS wrapper library like jQuery). For me, coming from a LAMP background before learning ASP.NET, I absolutely love C# and Visual Studio, but I'm not such a huge fan of the high level ASP.NET controls.
This is a pretty broad question, and hard to address. I perceive myself in a similar space to you, so I guess I can elaborate on what I've been focusing on to improve as a developer which might be of some help.
I mostly write business and commerce related web apps, and my focus has been on a developing a solid understanding of separation of concerns, domain driven design, and enterprise design patterns.
Some books on general software design which I found revelatory were Code Complete by Steve McConnell and Head First Design Patterns by Freeman & Freeman.
I read SO, Code Better, DDD Step by Step, and a number of other blogs regularly.
Dissect well written code from others, and learn from them. Learn from your peers. If you're in a stifling work environment that doesn't give you the opportunity to grow as a developer, consider looking for a new job.
Learn a new language in a completely different framework - I've been teaching myself Ruby on Rails at home and it has given me an interesting perspective on the ASP.NET work that I do commercially.
Given that you're an ASP.NET web developer, learning MVC.NET will certainly help you to think about front-end development in a new, refreshing way.
If you can afford the money and time (or can get your company to pay for it), take a course at DevelopMentor. They have courses across the country and all year round. They are generally a week long and are in depth.
We are currently designing a business application that has two primary requirements for it's UI:
1) run on the Desktop (WPF) for enterprise users to provide a rich user interface, interoperate with other applications, access the filesystem, work offline, work with special local hardware, etc.
2) run on ASP.NET/Ajax to provide several components of this application to customers (internet). Unfortunately Silverlight is not (yet) an option.
Even though we don't have to make the full application available on the web, some of these components are fairly complex and we would like to share as much UI code as possible with the WPF implementation.
What options do we have to reach this goal? Is there a pattern that works well with both technologies?
Update:
Thanks for the answers even though they don't include the one I was looking for! :)
I don't think UI generators are a good option. Like Eduardo pointed out you will probably end up with problems in both worlds. I will check out Sculpture though.
I've been thinking along these lines for a while now, and I've yet to come up with a great answer. That being said, here are some of my thoughts:
If you used some variation of the various MVP/MVC/MVVM UI methodologies and you were very disciplined in this approach (i.e. not mixing presentation stuff with behavior stuff), you'd probably be farther down the road.
You might consider investigating the various DSL toolkits that have cropped up, the idea being to create a simple "language" to describe your UI at a high level and generate a representation of that UI in WPF/ASPX.
Also, I ran across this recently. I have no idea how good it is. I'm planning to take a closer look when I get the chance.
Good luck!
The unfortunate truth is that Asp.net/ajax (the web in general for that matter) and WPF (and heck, let's throw WinForms in there for good measure) have very different User Interface models and what works well for one is not necessarily going to work well for another. That's not to say that you can't share logic between applications written for either technology, but, I'll make a stretch here, your UI logic is not going to be in that category.
I've been using a variation of MVVM for WPF and ASP.Net MVC most recently and I'd say they are very good fits for the technology at hand. However, while they are very similar, they have their differences and I'm not sure you could write an abstraction layer (in any decent amount of time) that could take advantage of the great features in both technologies.
Ultimately, I'd say that your best bet is to follow some SOA patterns and extract as much of your business and data access logic into common libraries as possible. Then, write separate user interfaces in WPF and Asp.net to take advantage of those common libraries. This is the approach that my company is taking at the moment, and it's working like a charm.
It may seem daunting to write your UI logic twice (once for asp.net and once for wpf), but I think it's worth it so that your code can fit the patterns and practices that best fit those technologies.
As an aside, even though Silverlight is not an option, have you considered XBAP?
If a former job we did something similar. As Daniel Pratt says, we describe our interfaces in XML and then a render will create the form, report or whatever we decided to create.
We have to provide a Javascript function to do some UI validations in the HTML render, and a call to a java function in the Swing render.
Beware that you may end with imperfect apps in both worlds.