I would like to know which steps and which concepts do you follow when you're starting a web application from scratch.
When you're asked to develop a new web application and the only thing you're told is which features are wanted, how do you do ?
How and in which order do you conceive all the different layers in your application, from the database design to the UI design, without forgetting the back-end ...
Which tools do you use ? which rules do you follow ?
Thanks in advance.
I like to start with a story board. I use mock screens for the examples.
I find this article very resourceful.
Hope it helps :)
Structured process you must know to develope a web appplication
Any answer to this question is exceptionally subjective.
In regard to how and in what order, you can refer to these threads, which are clearly inconclusive:
Which is more important? DB design or coding?
https://stackoverflow.com/questions/329160?sort=votes#sort-top
In regard to the tools, here is a thread:
What do you use for web development and why you think it rocks?
The rules you follow are partially tied to the tools you use, and partially tied to the design you choose. You should have a sense of the benefits and limitations of available frameworks and tools to do what you need done.
In designing the app, you can do as much pre-planning as you feel is necessary to understand the problem (i.e: story-boarding, ui mockups, entity relationship diagramming, functional specifications, etc.). The goal is to know what problems you are solving and what interactions you expect the user to enact on the application, and then use suitable technologies to achieve that goal - optimally in the most efficient and flexible manner possible.
Try to write a bit of a functional specification, just something simple to capture in writing the different functions that the app will have to handle. Once you have this done, you can sit down and work out what framework / language / platform / etc. best suits your needs. At this stage mockups will also help - try to find out exactly what screens you need and what information has to be on each screen - don't worry about the layout, just the necessary information. From there you can go on to coding up each of these screens - make sure that you only provide functionality that is in your design - there's no need to overcomplicate things just because you can.
Related
I am building a second Rails web-app from scratch. I am wonder what would be the best practice in terms of workflow:
start coding basic functionalities, then add GUI design and repeat,
or
create full set of wireframes for basic functionalities, then
design data and models, then code it up, then repeat
It seems to me that laying out wireframes forces me to think harder about how users will use the app, but choosing work-flow kinda depends on framework (support agile development or not).
What is your approach and what're pros and cons?
Thank you.
There's no "best"; it depends on what's actually happening.
You may know some basic functionality before beginning workflow design, but it's unlikely you'll know all of it. Either way, high-level behavioral tests are a good place to start defining functionality at both the UX and lower levels.
I'm not sure what you mean by "support agile development or not", that doesn't have anything to do with the framework. The framework shouldn't have an impact on workflow, either, only on how the workflow is implemented.
I have just started looking into .net MVC and I really like it.
There are a few developers within our team who think the same. But before we are allowed to use it for any project we need to get the approval of management.
What would be the best way to convince management(which know little about programming) that this would worth while and it could have some cost benefit?
My belief is that it will force us to write better more accessible sites which are a lot more testable than web forms. Which in return would mean less bugs and higher customer satisfaction. But I have no evidence of this.
EDIT:
We have a team meeting in 4 days, this is where I will be making my pitch to the team and management.That gives me two weeks to learn more on MVC and do a presentation.
Ok, I'm a manager. I've been one for more than 10 years. Luckily, I've been able to stay very current with my technology passions, so I think I can speak from both sides of the fence.
Managers are going to be concerned with three things here: risk, cost, and the status quo. So, when you present your plan, you're going to need to address each of these:
Risk:
Explain to them that the risk here is very low.
MVC2 is just an extension of MVC, both of which has full source code available (management speak: if we find a problem, we don't need support. We can fix it ourselves).
There's a ton of community support. (management speak: I can go online and get answers to any questions I have in a matter of minutes).
Heavy-hitters at Microsoft are pushing this (management speak: Microsoft is encouraging their developers to use this technology).
Cost
Talk about the fact that the technology is free, with a ton of community support.
Be ready to talk about ramp-up costs for any developers that don't have MVC experience. They're going to be less productive at first. Let your manager know that the developers will come up to speed quickly, and that MVC provides more efficient coding approach than traditional web forms.
Be ready to talk about costs and risks associated with ongoing maintenance. If you've already got a ton of web forms out in the wild, this will present a second skillset that developers will need to maintain. Find ways to convince management that it will be possible to maintain this skillset.
Status Quo
Many people become managers because they want a level of security and control in their life. If this is the case with your manager, they'll be interested in maintaining a comfortable status quo, and not making significant changes. If that's true here, you need to make the case that this really isn't a major change from what's being done today. Assure them that you have a back-out strategy. Talk about how this is really a proof-of-concept for MVC use in your organization, and that management will have an opportunity to review the success of the project prior to you ever suggesting MVC become a standard.
Really what it comes down to is the fact that ASP.NET MVC forces developers to write better, more scalable, and easier to test code. It moves them away from the crapshoot that webforms often can be, and in a direction oriented toward quality architecture and good clean code that follows more rigid conventions.
One definite drawback of MVC is that the View structure required by the webforms view engine (default) encourages you to write spaghetti code in the views that is, at times, a nightmare to maintain. Given this fact, you might even want to pitch them with the new Razor View Engine that was recently announced. With it you can write some extremely clean view code that even the non-developers at your company could manipulate without bringing mass death and destruction to your application. Compared to the markup in the webforms view engine, Razor's markup is pretty much beautiful.
Also, check out this really solid blog post by my buddy Matt Hidinger which does a great job of breaking down why MVC is so awesome.
When you speak to management just be sure to emphasize the all good points mentioned so far, and then compare them to all the bad that webforms is/can be. Be practical and realistic; if you have enough people on your team that are ready to jump on board with MVC then it's pretty much the best possible decision you can make, in my opinion, anyway. You may even want to take a moment to show them some of the great sites that use it- like Stack Overflow.
Personally, I have launched about 15 separate sites built with ASP.NET MVC and as such I feel I have a pretty solid understanding of it. I can wholeheartedly tell you, from my experience, MVC is the best thing that ever happened to ASP.NET.
It really depends on what you're comparing it to, but assuming it's an alternative to webforms, a few items to mention:
better testability
more control over output, which can help target other devices
leverage existing knowledge of .net
MVC framework encourages you to write more structured, testable and, as a result, more maintainable code. As the biggest costs in development are in the debugging and maintenance, those benefits alone should be a good validation. That said, it's still possible to code crap in MVC and that shouldn't be overlooked. If your company has a lot of expertise in another development framework then you really need to address the deficiencies in that and how MVC can rectify those deficiencies.
I would start by looking up blog sites that support MVC and compiling some of the advantageous features of MVC. I would start with Scott Guthrie's initial blog post regarding MVC - it outlines some great features - http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx
If you are looking at trying to bring MVC in and need to convince management of the value, your best approach is too show how it can reduce long term support costs. Having an application that has well developed unit tests with decent code coverage can ensure quality over the life cycle of the application because you can higher level of confidence that changes you introduce have not broken pieces of the application. This doesn't negate the need to test the application, but you will find breaking changes faster. An approach utilizing MVC over MVC is a much more flexible platform for this testing.
There are many studies you can utilize that show the long terms support/maintenance costs of an application are often greater than the initial development costs. Stephen McConnell's Code First has a good discussion of this.
Good luck!
As opposed to what? Management would rather you wrote poorly-designed code? I'm surprised it's even an issue, in that whatever else they're asking you to do, by the current state of the industry, is self-evidently the wrong decision. If they know what MVC is, I can't see how any reasonable person would want you not to use it.
Sell it as an ASP.NET component, only made by Microsoft to incorporate some of the newer web 2.0 technologies moving forward. Tell them it will enhance maintainability while reducing development time. Tell them it uses existing infrastructure, and is more performant. Tell them it uses existing investments in training and software. Tell them it is more efficient, and makes it easier to fix issues and build enhancements. Tell them they'll get more out of their development team without allocating more resources.
I am building a site that has a lot in common with a person-on-person chess site. I was thinking of using Rails for the front-end(User Registration, Navigation, etc) and something like Scala or Erlang for the engine(Game state and maybe AI). I was wondering -
Is this a good situation to use that type of design?
How exactly would be best to divide up the functionality between the components?
How would they best communicate with each other?
I'm open to any technologies or ideas.
If you're using Rails for the front-end, why not use Ruby?
If you like the idea of using Scala, why not use Lift for the front-end?
Chess is turn-based, and has a very simple board that can be handled with HTML and/or Javascript enhancements - so the basic model flows quite nicely with existing web frameworks.
With this in mind, Rails is a great choice for creating a web-based application. Rails is not just limited to crud applications, and in fact I think can write your entire app in Rails/Ruby - you don't really need to have an external engine.
Within the browser space, polling for turn updates can be done using XMLHttpRequest and a database can maintain the current game and turn state.
Looks like a simple Lift application to me. I'm not experienced with Lift, mind you, but it doesn't seem particularly more complex than the chat application that is so often demoed.
I would start by reading http://www.htdp.org/ How to Design Programs. The questions you have asked are very broad and difficult to answer without prefixing statements with "I believe that..."
I would code it in clojure (but that's just me).
I'm currently developing a suite of online games, using Scala. It's been absolutely fantastic - my game logic is much easier to get right with the static typing etc, and dealing with server/client protocol (a flash client, in this case) is made simpler via the use of Google Protocol Buffers.
If you're a huge fan of RoR, by all means use that. I think most statically typed languages are terrible to program websites in (Java, I'm looking at you here), but Scala gets rid of 90% of the pain, and gives even more safety.
Of course, it might not be your cup of tea. But I'd try just doing the entire thing in Scala, and adding another layer if that doesn't quite do it for you.
For question 1 Yes
And for 2 and 3 you need to give more information in order to get an answer that could help you.
Now I'm doing something like you but for the front end I'm going to use Grails. The reason are very simple: I like Grails, Scala and I want to mix them :)
When writing code for a new system I don't want to introduce unnecessary complexity in the design that I might never have any need for. So I'm following YAGNI here, and rather refactoring as I see the need for more flexibility or as responsibilities becomes more clear. This allows me to move faster.
But there is a problem here with junior devs, in that they will not recognize when to refactor or where build out the design. They just stuff more code into the existing design.
So, what are the best ways to tackle this? Should I more often build a more future-proof design so when adding to it they have a good example to follow, even if we might never have to add anything? Or should I just go ahead with more code reviews, education, etc? Or both?
Have any of you had any experience with this type of problem? How did you solve it?
I would recommend code reviews or pair programming. It gives you the chance to educate your fellow developers and increase the overall quality.
Perhaps you begin by recognizing explicitly that part of your job is to help develop the junior devs. If you're not the boss, management should sign off on this. Management needs to recognize that your choices are to develop them now or clean up after them later, and you need management's backing for the time this will take.
Code reviews and pair programming are fine ideas. They are especially good because they are not "just for junior people"–I do both with one of my close colleagues; together we are nearly 100 years old and have more than 70 years of programming experience :-)
But there's a larger problem here: the programming methodology that enables you to be most effective (YAGNI + refactor) is not effective for your junior partners. My experience is that it takes people years to learn the benefits of YAGNI, so if you expect them just to learn your way of doing things, you are setting yourself up for disappointment.
I would encourage you to identify some methodology that you think is going to be useful with your junior partners. The particular methodology probably doesn't matter (heresy!); I've had success with composite/structured design, object-based design, algebraic specification (!), and extreme programming. But
Do pick something that has a name and some literature devoted to it, that your juniors can take pride in learning, and that is a skill they can carry to future projects.
In order to show that it is tasty, you may need to eat the dog food yourself. Pick something you can live with and be productive in.
Observe your juniors carefully and teach them a decision procedure they can use to identify when they should ask you for guidance.
Good luck!
There is a reason they are junior and you are senior.
The ability to realise when a change in design is needed is one of them.
I would carry on as you are but encourage them to come to you when things are getting difficult. You can then work with them to alter the design if needed, this will be easier for you than refactoring it and will help you pass on knowledge to your junior developers.
A very good way to show how far to build out a design is to be specify about what the design will do when built out, then write tests to cover the new functionality. When the tests pass, development is done.
You might realize along the way that you forgot to test for something. That's fine, and is useful feedback to help you specify better next time. Write the missing test(s), and only enough code to make them pass.
Then refactor. Knowing what to look for when refactoring takes a bit of practice. Start with
Is there duplication in the code we've just written that we can eliminate?
Is there duplication between what we've just written and pre-existing code?
Does the code we've just written concern itself with too many things? (I.e., should we break out collaborators?)
Repeat this a few dozen times, and it'll get easier.
Another way of looking at YAGNI is that any changes to code need to be justified.
Might it be helpful to require any commit needs an associated unit test (or BDD user story, choose your poison)? It helps to communicate your intent (you want people to think about why they are adding this feature) and you get regression tests for free.
Also gets the noobs to start thinking about modularity (usually needed to make your code testable) and will help a lot if you do need to refactor later on.
I'm all for code reviews and teaching, but I think futureproof design is also important. Maybe you could think of it in terms of you designing an API and the junior developers using the API. In this way you are the one who does the hard work that they would screw up (identifying duplicated code and eliminating it) while they do all the grunt work that isn't a productive use of your time.
Of course this has to be balanced with a need to develop your junior developers skills. Neither side of the equation can be neglected.
It may help to map out what work they will do and then verify it to help build their sense of judgement which is really what you are asking, to my mind. Pairing is one option but if you can't spare that much time then having a sort of "check point" to see how they are doing and preventing them from going down the wrong path.
What language, framework, and hosting considerations should one make before starting development of a scalable web application?
The most important consideration is not to over-engineer to the point that it gets in the way of building and launching something. Analysis paralysis is the single biggest inhibitor to productivity, progress and results.
Yes, do some planning. Pick a framework. Perfection in a framework will be impossible to find because it doesn't exist, partially because you don't know what you need until you build it anyways. Chances are, if you pick something, it will be better than picking nothing.
Yes, try to pick flexible, inter-operable tools for where you see yourself going.
Yes, look for a good built-in feature set where you see yourself going in the next 6-18 Months. Trying to look beyond that is not really realistic anyways as most projects change so much anyways going towards the first release.
So, pick what you're comfortable with or what is familiar. Don't follow the crowd, do what gets you the best results, quickest, and often. Understand that you might have to change in the future. So, whatever you build now, try to use unit testing so you can re-factor if ever needed.
If what you're building is going to be super successful, it will be a great problem to have, and an easy one to work on once it's making money as you'll be able to get other talent to help you.
Share what you end up picking and why for your situation -- it helps the us learn from you too!
Don't necessarily marry yourself to one language or framework. It may be that some parts of your site work better with different languages and frameworks than others. For example, all of 37signals' sites are based on Ruby on Rails, but they recently wrote a blog post about how the underlying technology of one is actually written in Erlang now because it's much easier to do concurrency that way.
Obviously there's a level of complexity where things turn into a mishmash, but using the right tool for the job — even if that means different tools for different jobs — can simplify things.
Firstly on language, it largely doesn't matter. PHP, Java and .Net being probably the biggest three are all proven in the sense that they run some of the largest sites on the Web so don't listen to anyone who tells you one is more suited than any of the others.
Some might also put Ruby and Django/Python in this list. I have nothing against them but I'm not aware of any big (say top 50) sites using either.
Hosting considerations depend on how low you want to start but basically the order is:
Shared;
Virtual Private Server;
Dedicated.
Scalability will largely be about your application's design than any language, framework or provider. Efficient database schema, efficient delivery and use of Javascript/CSS and in-memory caching are all issues common to any language or framework.
Language - I'd recommend something with good frameworks and good testing libraries like Perl or Java.
Framework - it depends on what do you plan to do. If you start with a hosting that does not allow FastCGI, it is best to avoid such frameworks like Catalyst or Rails. That's why I love CGI::Application (primarily Perl, but ported to other languages too) - it can run as CGI, FastCGI or mod_perl. For development it can be run from it's own web server.
Hosting - nothing is better than you own server. It can be your own server, leased server or virtual server. But you can start with cheapest hosting and when you need more, you should be able to afford it.
It depends.
Start by looking at your requirements (Functional or user defined) (Non Functional - aspects that describe your desired system link text)
Next I would clarify what it means to have a scalable web application. Define it as test cases that can be clearly tested (must support X page views / second with response time < Y seconds).
Once I had those pieces in place I would look at what type of skills my development team can support (for the intial project and on going maintenance). Then find some case studies of applications out in the wild that use similar language or framework. If someone else has made a specific language / framework scale then chances are good that you can too.
Finally go out and look for some hosting providers that support your chosen language, framework and requirements.