Years ago (pre-web) I used to be a Fortran developer (yes it was a very long time ago!) but these days I run a small non-IT business. I would like to develop a database application for my clients to access via a browser (or maybe down the line via a mobile phone). I haven't done any programming for a while apart from some VB macros in Microsoft Excel. I would be grateful if anyone could suggest the best language/technology to learn to get me heading in the right direction.
As Neil said in his comments there are dozens of different, valid answers to this.
Usually I would suggest going with a language you already know, but neither Fortran or VBA are really suited for this task, as far as I know.
Personally I would suggest Django, which is a web framework written in Python. It simplifies many common tasks and it is very well documented.
But there are many more possible solutions.
Before I started with a framework I'd break the problem into pieces. If you've never done anything with a database before you'll find that challenging enough without piling web or mobile on top of it.
Model your problem and get a good object or data model in place. Test that thoroughly without thinking about UI. Once you have that, perhaps you can expose it as services that any UI can call.
You'll quickly become overwhelmed if you try to do it all at once.
Here's another thought: If these are paying customers, why not do yourself and them a favor and hire someone that knows how to do this? It's great that you used to write Fortran, but if you haven't kept up you won't be doing your business any good by putting out a bad first effort for customers to see.
Do it right - get a professional. Do your learning on your own time.
You can use ASP.NET and SQL Server to get something online that will allow users to edit a database table fairly easily. They've simplified it to the point where you can drag and drop the necessary controls (GridView and a SqlDataSource for instance) and define your datasource in a wizard for most simple table CRUD functionality. Basically give users the ability to edit a table without writing any code.
If you need to do something a little more difficult it's easy to write code that will add functionality to the original drag/drop stuff you did.
There are lots of good resources out there for asp.net and C# also, so it will help you get up to speed quickly.
Keep in mind that I work almost entirely with .NET/SQL Server so my opinion will be slanted towards them...
Currently as my job profile i am more working on asp .net application but i also wanted to have my hands on silverlight application. so, i just decided to build one silverlight 4 application in my spare time and on weekends.
We are having a team of around 4 people. We also tried for commercial application but as we can only develop it in our available time we can not commit on timeline as well as we people are new to SL, so first we need to learn concept and implement it. (Though we know the concept of binding, commanding,templates etc.)
Now i just thought to work on project like creating a social networking site in SL 4
having facilities like forum, blogs, calander, task, dashboard etc.
We want to use features like .Net RIA Service, Entity Framework, MVVM pattern, SL 4.
Objective here is to learn new concepts as well as to get some good project experince in silverlight.
Now,
what you people suggest is it a good idea ?
If yes then the project selected is correct or you suggest some other project ?
Any pattern or technology related suggestions ?
This is quite a vague set of questions but I'll attempt to give my 2 pennies worth of advice.
As a learning project this is as good an idea as any to get going with. As a commercial idea it probably isn't such a good one due to there not being any niche in your product. It has all already been done, and been done successfully by the likes of Facebook and Twitter. Developing any kind of social media site is incredibly difficult as the market is already fairly saturated. As I said though, as a learning project it's quite nice as you can just borrow concepts and ideas from other sites and you can concentrate on you main goals of gaining knowledge in the various technologies.
Whatever you decide to do I'd say split the project up into much smaller components rather than having the end goal in sight. Try to take more of an agile approach by setting yourself 2-3 week targets. It should help keep the momentum going. My experience is that learning projects tend to die a death as people get bored of the concept and lose motivation to do it. By keeping the tasks small you get to see small results often. This should help keep you motivated as you move from requirement to requirement.
Personally I think setting up personal projects and goals like this are a great way of learning new technologies - good for you!! :-)
From a tooling perspective it sounds like SL4 is an ideal route to follow. This is highly likely to be released in early 2010 and has some awesome new features compared to SL3. Would also recommend using VS2010 and WCF RIA Service too.
From a code sharing POV have you considered hosting your project on Codeplex? This will give you a hosted TFS server to manage your source code in a distributed way. This is bound to save you some big bucks.
As far as document management is concerned Google Docs are certainly worth a look (as is Google Sites as a really easy to set up (albeit simple) project management portal).
Finally, I can't recommend learning SketchFlow highly enough. As a prototyping tool for silverlight it is really, really cool. Take a look at the PDC video for a great kick start on this.
Good luck :-)
I'm getting ready to develop my first Silverlight app. It is going to be primarily used by my church for data input but also will need to generate at least one report, ideally in Excel but XML/XSLT is not outside the realm...
It will be Internet facing and will talk to a SQL Server 2008 db for which I will be creating a web service hosted at the ISP (db is also hosted at the ISP). The clients will be a mix of Windows and Mac.
My question specifically relates to the interface architecture. I know MVVM is big for this right now and I'm comfortable with that. I want to get this up fairly quickly (ie- next 3-4 weeks). I've also seen mention of Prism (Composite Application Guidance) and Caliburn. What are anyone's thoughts on these two? The initial version of the app is not going to be huge so I don't imagine it would be overly difficult to refactor a framework into it at a later date.
You are right, if it's your first development on SL, adding the complexity of MVVM won't help you much.
I think a good approach could be to go for something simple (e.g.: the good old Document/View could be just a good start http://msdn.microsoft.com/en-us/library/4x1xy43a(VS.80).aspx, or just breaking in standard layers, UI / BS / DL).
After that development you will have learnt a lot of good stuff, and then you will be able to throw your app and start new bigger challenges using more advanced architectures (about MVVM, a very good web cast: http://blog.lab49.com/archives/2650 it's WPF based most of the concepts can be ported to SL).
Good luck and enjoy for SL development.
Cheers
Braulio
Start with something you are very comfortable with especially if you need to get this up quickly. Follow good coding standards and should not be a problem to refactor later into other frameworks if you get a bigger team.
This is a useful pdf.
I haven't read it in detail yet myself, but this article looks rather useful:
RIA Architecture with Silverlight in mind
We have a large suite of apps, most are C# 1.1, but at least 10 major ones are in VB6. We are undertaking a project to bring up the VB6 apps to .NET 3.5.
All the c# 1.1 apps are written using a traditional n-Tier approach. There isn't really any architecture/separation to the UI layer. Most of the code just responds to events and goes from there. I would say that from the point of maintainability, it's been pretty good and it's easy to follow code and come up to speed on new apps.
As we are porting VB6 apps, the initial thinking was that we should stick to the existing pattern (e.g. n-Tier).
I am wondering, whether it's worth it breaking the pattern and doing VB6 apps using teh MVP/MVC pattern? Are MVC/MVP winform apps really easier to maintain? I worked on a MVC-based project and did not feel that it was easier to maintain at all, but that's just one project.
What are some of the experiences and advice out there?
Dude, if something works for you, you guys are comfortable with it, and your team is up to specs with it. Why do you need to change?
MVC/MVP sounds good... Then why am I still working on n-Tier myself?
I think before you commit resources to actual development on this new way of programming... You should consider if it works for YOUR team.
If you are porting the VB6 apps vs. a full rewrite, I'd suggest to focus on your Pri 1 goal - to get asap to the .Net world. Just doing this would have quite a lot of benefits for your org.
Once you are there, you can evaluate whether it's benefitial to you to invest into rearchitecting these apps.
If you are doing full rewrite, I'd say take the plunge and go for MVP/MVVM patterned WPF apps. WPF willl give you nicer visuals. The MVP/MVVM pattern will give you unit testability for all layers, including the visual. I also assume that these apps are related, so chances are you might be able to actually reuse your models and views. (though, I might be wrong here)
It moves a thin layer of code you still probably have on the UI. I say thin, because from your description you probably have plenty of code elsewhere.
What this gives you is the ability to unit test that thin layer of code.
Update 1: I don't recommend to re architect while doing the upgrade, the extra effort is best expend on getting automated tests (unit/integration/system) - since you will have to be testing the upgrade works anyway. Once you have the tests in place, you can make gradual changes to the application with the comfort of having tests to back the changes.
MVC in particular does not exclude n-Tier architecture.
We also have ASP.NET 1.1 business application, and I find it a real nightmare to maintain. When event handlers do whatever they like, maybe tweak other controls, maybe call something in business logic, maybe talk directly to the database, it is only by chance that software works at all.
With MVC if used correctly you can see the way the data flows from the database to your UI and backwards. It makes it easier to track the errors if you got the unexpected behaviour.
At least, it is so with my own little project.
I'll make the point once again: whatever pattern you use, stick to the clear n-Tier architecture. 2-Tier or 3-Tier, just don't mess everything into a big interconnected ball.
"Change - that activity we engage in to give the allusion of progress." - Dilbert
Seriously though, just getting your development environment and deployment platforms up to .NET 3.51 is a big step in and of itself. I would recommend that things like security reviews and code walkthroughs should probably come before re-archecting the application.
MVC and MVVM are excellent paradimes, particulary in terms of testability. Don't forget about them, but perhaps you should consider a pilot project before full scale adoption?
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 5 years ago.
Improve this question
The rich presentational capabilities of WPF and Silverlight mean developers like me will be working closely with graphic designers more often these days, as is the case in my next project.
Does anyone out there have any tips and experience (from both points of view) on making this go more smoothly?
For example, when I mentioned source control to a designer recently, I was quickly told you can't source control graphics, images etc, so it is a waste of time. So I responded: ok but, what about XAML files in WPF/Silverlight?
Scott Hanselman spoke about this topic in a podcast, but he focused more on the tools, while I'm more interested in the communication issues/aspects.
One of the things I've discovered is that how you as a developer design your code greatly affects what the designer can do with it. Often you download a Silverlight or WPF sample application from the web and open it up in Blend, just to have Blend crash on you because the code doesn't run well inside the designer. If it doesn't crash, it seldom look anything like the running application.
I recently gave a talk at Tech Ed Australia and New Zealand about techniques you can apply to "design for designability". A short bulled list is included:
Write code that can take advantage of data binding. The Model-View-ViewModel or the presentation pattern is a good fit for this.
Supply "design time" stubs for your service dependencies. If the class you are binding against makes web service calls be sure to replace the web service client with a stub class that returns "dummy data" that the designer consumes inside blend. This can easily be done through IoC and Dependency Injection, injecting one implementation if HtmlPage.IsEnabled == false.
By using data binding you can limit the number of "named elements" you have in your XAML file. If you write allot of code behind you end up coupling your C# code against named elements such as txtName or txtAddress, making it easy for the designer to "screw up".
Use a command pattern instead of code behind click event handlers. By loosely couple the invoker of an event from the handler you can have less named elements, and you give the designer the freedom to choose between a Button or a Menu Item to invoke a specific command.
Test your code in Blend! Even if you consider your self a pure developer you should test that your code is consumable by a tool, and strive to get a best possible experience at design time. Some would argue that a tool shouldn't effect your software design, just as some one complains about "design for testability", and making software design decisions just to make the code more testable. I think it's a smart thing to do, and the only way you can get some real designer-developer work flow going.
Other tips would be to start small. If your designer is new to XAML, WPF and Silverlight, start by introducing them to the project team, and have them do some basic designs in the tools they know. Let them do some buttons and illustrations in Adobe Illustrator, and export it to XAML, and show them how you can leverage their design assets directly. Continue by introducing more and more, and hopefully they get interested and want to make the switch to Blend. It's quite a learning curve, but it sure is worth it!
Good luck!
PS: I have written allot about patterns and making designer friendly code on my blog at http://jonas.follesoe.no. You can also find links to a video recording of my Tech Ed talk, as well as lots of links to further reading on the topic.
I have spent 4 months on a project working extremely closely with a designer and he has still not picked up the basic idea of CVS (which is not my choice of source control system). I'm talking template files, JavaScript and CSS here. He's not stupid, it's just one of these things that makes his job harder so he resists fully commiting himself to it.
In my case I had to really hammer home the point that almost all of my JavaScript depended on the mark-up and when he changed his pure CSS, DIV-based layout into a table-based one without telling me then all my JS is going to break.
Often during the course of the project myself and the designer, who I get on with quite well and play soccer with outside of work, had very heated exchanges about our respective responsibilities. If I didn't know him well enough to just get past these exchanges then I think it would have created an unbearable working environment. So I think it's important you establish between you both and with some sort of manager or project supervisor exactly what is expected of both parties during the project.
In my case there have been very few problems lately, because the situation with CVS has been sorted out as well as the idea that he can't just go and change the mark-up whenever he feels like it. Rather than try and create template files and work on them directly, the designer only works on static files and its my responsibility to plug them into my template files.
It's all about communication and a little bit of compromise on both sides.
This may be a bit off topic (I'm replying specifically to your question about source control and graphics), but you can put binary data (images etc.) into source control (and in my opinion in a lot of cases should) -- they just take up more disk space and you can't use a diff view to analyze what has changed in any meaningful way, but what you do gain is a history of commit messages documenting each revision, rollback ability and the ability to easily archive (tagging a revision in SVN terms) all files (be they visual assets, documentation, source code, whatever) belonging to a specific release/version together. It's also easier for your build system to just fetch everything required for building a specific version of your software from the source control.
Involve the graphic designer in early design and architecture sessions.
You want to involve them to reveal misaligned assumptions and to establish a pattern of working together rather than throwing things back and forth over the wall.
Originally, it was envisioned that professional designers would work in Expression Blend, and developers would work in Visual Studio, making changes to a single shared set of source files. While it is certainly possible to do that (so long as you are careful to check regularly that you haven't broken something expected by the other dev. or design tool), many members of the developer community, including some inside Microsoft, have discovered benefits in keeping Blend and Visual Studio project activity SEPARATE -- even to the point of manually cutting and pasting carefully-refactored versions of Blend-generated Xaml into the "official" VStudio project source, rather than allowing designers and developers operate directly on a single shared code base. Microsoft's User Experience Team in the UK published a video describing the problems they ran into trying to coordinate designer and developer efforts on actual projects.
Real_World_WPF_DesignersAndDevelopersWorkingTogether
One of the main lessons learned is that you can't staff a project with designers and developers who are completely ignorant of each other's domains. Developers need to be familiar enough with Blend that they can provide designers with useful UI shells for the designer to decorate, and useful data "stubs" the designer can design interactivity against, and the designer needs to have enough understanding of development issues that they don't do things like delete controls and replace them with custom visual elements - not realizing that they broke all the functionality tied to the original control.
Microsoft's vision of the designer/developer workflow marriage definitely seems to break down in real life. I have experience working on a fairly large scale WPF project which involved 2 dedicated design resources for about 4 months. Here are some facts that Microsoft seems to often forget.
Designers often prefer to use Macs (designers at my company are 100% Mac - 0% Windows)
Blend doesn't run on a Mac (as far as VM solutions - designers typically don't like geeky solutions like running weird applications in a foreign OS).
Designers use their tools of the trade - Photoshop and Illustrator. Period.
The aggressiveness of today's schedules usually don't provide ample time for designers to learn a totally new application / design environment (like Blend).
So given the above, what I noticed was that this creates a new job type - either a very techy designer or a graphically enlightened programmer. Basically, someone who can take the design assets in raw form - usually .psd or illustrator format and apply these as needed to the application process.
I turned out to be that guy (graphically enlightened programmer). I spent a lot of time exporting XAML from Illustrator files, cleaning them up by hand when necessary, and making these assets easily usable display objects in Blend or VS. There were also times where I would take a a design element and re-draw it using blend ( usually when the original asset was bitmap based and it made more sense to convert it to vector).
My application may not have been typical - as it was extremely graphically rich and resolution independence was one of the main objectives as it needed to look good on multiple resolutions and aspect ratios (think of the difficulties in designing for TV in todays landscape - things have to look good in both low-res SD and scale well up to hi-res HD).
In summary, I think WPF is an awesome technology and absolutely a step in the right direction for Microsoft. It however is not the end-all be-all solution for integrating the designer in the development process - unless you redefine the role of designer.
I'm Felix Corke, the designer from the hanselman podcast you mentioned, so here are a couple of points from a genuine creative as opposed to a developer.
It took a long time to become used to developer tools - I'd never heard of Visual Studio, C# or any type of source control when I first started doing xaml work a few years ago. They were as alien to me as maybe Illustrator or 3DsMax would be to you.
My biggest single point is that the designer can't be expected to know developer practices - please be prepared to do a great deal of hand-holding. You won't have to learn anything new whereas the designer will be launched into a whole new scary side of app development. I made a right mess of a few solutions and checkins (and still do).
Happily, I've learned to become more of an design focussed integrator than a straight creative, and maybe this is a role you need to include in your project. This is the illustration I made for our beauty and the geek - designer/developer session at Mix - if either of you is at too far at either end of the spectrum it can be difficult understand how the other works and what their role should be.
Happy to answer any specific questions!
ps you do NOT want 100Mb+ .psd files in source control ;)
The extent to which designers have come to feel entitled to be distant from the whole of the work involved in building a software product is a much bigger problem that needs to be solved. Don't pander to any designer's expressed right to not have to know how their work gets integrated into the whole.
The kind of stark specialization that has grown up in the designer community is one of the biggest industrial maturity problems that faces the software development industry. It's an extent of specialization that predictably creates more rework and longer cycle times.
This is also true of developers' sense of entitlement to go blissfully unaware of interaction design and implementation.
Extreme specialization is always an exponential multiplier in productivity problems. Solve it organizationally by adopting processes that promote learning cultures. This is the level of maturity that most other production industries have already realized, and that software drags woefully behind.
At every place in a development workflow where handoffs occur between over-specialization, work queues and buffers form. Software remains one of the few industries that doesn't recognize this as one of the biggest problems we face. This is even more exacerbated in the Microsoft community as over-specialization seems ever-more normal due to Microsoft's perpetuation of over-specialization through its tools and guidance. Unless you can afford to waste as much money as Microsoft does in development efforts, you should look to methodologies that are much better informed on questions of flow and productivity.
Consequently, the developer who cannot test and the tester who cannot code is a symptom of the same industrial immaturity.
You won't learn any of this from the Scrum template for TFS. Microsoft was years behind the curve in getting agile thinking in-play even in its most rudimentary forms, and now that we're progressing into Lean thinking, Microsoft will be another three to five years away from trying to incorporate Lean thinking into its product lines. Don't wait for Microsoft to tell you how to shape a team and a workflow. You can learn right now from the people that Microsoft will ultimately pay attention to in a few years.
I'm a big believer in the Integrator approach which is really the role I have had to perform to make our WPF efforts successful.
Laurent Bugnion has a post on this that describes what I'm talking about. Robby Ingebretsen is also a big believer in this approach.
But basically, someone has to cover the 'gap' that exists between the developer world and designer world. What usually happens is that this person comes from either the developer world or the designer world. If they come from the developer world, then they are probably a developer with designer tendencies (they're responsible for look and feel, the visuals in the application, the layout of the screens, etc.). If they come from the designer world, then they aren't afraid of code and the enjoy diving down every now and then to code to get that animation or whatever sparkling.
However, regardless of what world they come from, they usually have to build skills that they never have had before. In my case, I am developer that loves the user interface layer and therefore I would say that I am a developer with designer tendencies. In order to cover that gap and have productive conversations with our graphics designer, I have had to pick up a whole bunch of designer type skills like: learning to use Expression Design, XAM 3D, etc.
Shannon Braun recently gave a presentation at a local developer conference about the developer/designer relationship and the workflows that the community is discovering works for them. I didn't attend the conference, but I thought his slides were a great discussion on the matter.
In my experience, the integrator or "devsigner" role really needs to be involved in this process unless everyone on the (small) team are able to perform this role. This is a very rare circumstance. Usually you will find that developers are very good at developing but aren't so great with design/usability and designers are great with aesthetics/usability but don't want to or are not educated enough to code. Having someone that can crossover into both worlds and "speak the language" is very important.
The integrator needs to coordinate the controls that are being developed with the design assets that are being created by the designers. In our current project, we have 6 active developers and 2 designers from an outside shop. I am the integrator for this project and I spend most of my day in Expression Blend. The developers work primarily in VS creating controls that meet our product spec and the design shop is designing what the end product will look like. The designers are working in Illustrator. My job is to take the Illustrator files and create control styles from them and then apply them to the controls developed by our development team. As we move towards Blend 3 with native support for PSD and AI files, this task becomes much easier.
It is very helpful to create the "look" for your application in a separate solution from the main trunk of the application and then merge your ResourceDictionaries into the main app later. You can get the look and feel correct without getting too caught up in what could still be incomplete controls.
I am going to assume that you refer to RIA projects since your mention of SL.
I have worked one quite a few RIA projects with Adobe designing and developing applications and services.
The best advice I can give you based on based on my 14 years experience as an UX and Visual designer with some programming experience although pathetic compared to you guys.
Accept that you wont understand each other.
The programmer thinks in what functionality should be done, the designer think in how the functionality should behave.
For the developer a button is mostly generic, for the designer it's not the case. Designers think in composition, developers think in frameworks.
So learn to understand that your responsibility is different.
You the developer DO need to think about how generic your code is and can't afford to treat everything as being unique and a hardcoded composition. That is unless you can automate that uniqueness somehow.
The designer DO need to think about the application or service as somehow unique. It might mean that a button is not a button. There might be different sizes or colors or other annoyances.
So make sure you develop a good relationship with the designer by acknowledging that you understand the designers responsibility and make sure he understands yours.
It's not that you are not interested in making the best application in the world. It's just that some of these design decisions takes quite a lot of time.
Make sure that you get very clear on how the designer should deliver to you so you don't waste his or your own time. What format, assets? Naming?
All things that are involved in delivery from one paradigme to another.
And most importantly communicate and respect that they don't know how to do JavaScript or how understand the basic ideas of CVS.
Most developers you wouldn't know how to kern to save their life, what a widow is, how to best layer FireWorks or create a photo-realistic icon, come up with a good tagline or make something understandable to average Joe in 4 words. You don't know what a grid or alignment is and you tend to make things green and purple on black.
And the designer should understand that just because you deal with programming does not mean you are a robot, that you can't have creative ideas and solutions. He should also try to learn how to program at least pseudo program so that he understands what's involved in making your project.
And most importantly. Don't start to debate Mac vs. PC :) Projects have been canceled because of this.
Quite frankly you should tell the designer that images can, should and "will be put in source control mister!" :)
It may be slightly non-conventional and you wont be able to do a merge or anything of that nature, but there will be revisions and a history, etc .. Images can also be embedded in a resource file which goes into source control as well.
XAML can (and should) be put in source control and as its a markup file it will benefit from all of the features.
As far as tips from working with a designer, the one you are working with scares the heck outta me just by that comment alone, so it may all boil down to WHO you are working with. I would explain basic best practices in a nice manner and proceed from there.