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 8 years ago.
Improve this question
Can anyone explain what is windows workflow and how can we use in the work organization.
Windows Workflow Foundation is a fascinating concept. It allows you to create powerful applications (or just parts of them) using a combination of flowchart-like concepts and normal code.
The deeper value of this may not be immediately obvious. Say you're building a large e-commerce site. Over time, your workflows for processes such as fulfillment will change radically. The code will eventually become a horrid cludge of ideas shoehorned over old ideas. You will be forced to work up reams of documentation and in time it will become difficult to maintain.
So, workflow is ultimately about creating highly maintainable code with the idea that code will change. When you look at it, you're looking at a flowchart. Double-click on a node and it takes you to a code editor where you can write some business logic.
It's a lot more involved than that of course.
I have a book on this sitting on my desk right now. I am trying to determine whether the .NET implementation is ready for prime time or if it's still too new and complicated - and it is complicated, moreso than I expected.
At this point, I think the idea has the potential to be a game changer... We will see if the current generation is actually usable! The fact the Microsoft is not pushing it that hard is probably telling.
WF is a framework for creating workflows. It consists of a type of workflow (state machine or sequential), hosting different "activities" and logic controlling how application flow travels from one activity to another.
You can use it for describing business processes, from page flow in an ASP.NET application to the steps required to submit a vacation request.
Here's a great article about WF.
The Workflow Way: Understanding Windows Workflow Foundation
Windows Workflow Foundation puts the inner core concepts of development part right in front of you. So it becomes a little complex but a very powerful way of working and creating builds.
The basic Idea of development using the flowchart like concepts makes it very intuitive, it becomes very easy to trace the complete code without going through the code as it was previously done in traditional way of programming.
There are different other features of using workflow like parallel running of execution, drag and drop facilities of activities, using built-in activities as well as we can write our own custom activities and we can use those activities wherever we want in any other project.
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 7 years ago.
Improve this question
Im wondering how to kick-of projects for a single developer in proper way.
There are a lot of reasons why its not a good idea to just sitting down and hack the solution you want to reach without any plans or organisations.
In professional software engineering, there are a lot of required steps for planing a piece of software (like writing a vison and scope-document, doing requirements engineering and finaly planing the architecture).
But what are the common way for planning an application development endeavour for projects with just one single developer. For example: Do you use architecture-tempaltes like the well known arc42-Template. Do you thing its a littlebit unduly to doing such steps just for ideological reasons or is this the only right way?
What kind of Design-/Architecture-Templates so you use for planing projects?
Although you are a single developer I would consider using a Methodology for your development.
When you are working alone on a Product you will have to take up several roles to keep an overview.
I would recommend to use the RUP-Process.
It is an agile development approach which can be used be small or bigger groups. Although you are working alone you will profit from this methodology as it will make your Implementation easier. You can adapt the methodology to your needs and decide what is necessary or not for you.
The RUP-Process consitst of 4 Phases.
Inception:
In This Phase you are gathering all Requirements. Which means that you write down what you actually want to do before you start coding. Coding directly will quickly limit your creativity as you will soon encounter errors and forget what you actually want because you have to fix one problem. Take a week or two and write down everything you expect from your application. What it has to deliver or what could be a plus (in the next release for example).
Elaboration:
First you make the architectonial decisions. What db will you use. What language etc. Then you start coding. You are coding arround 80% of your application, leaving the hard stuff out at first. In this Phase you should finish the main parts of the GUI and have bindings to the methods used by the GUI. They do not have to be finished.
Construction
Now you tackle all Programming problems left and all the little errors which you have left out in the Elaboration Phase. It might be that you encouter new requirements. Estimate how long it would take you to add them in this release. You can then decide if you want to finish it or save it for the next inception phase. You should also finish all comments for the methods in your application.
Transition
Now you are Testing the Product before delivery and fix the last errors. Also you should be writing a Documentation of what you have implementet. If you have writting something down in the Inception it should not be to hard for you to write documentation.
When finished you can start another Cycle again starting with the inception.
CONS:
- It might be an overhead having a methodology for only one developer
- You might get annoyed
PROS
- You will have good requirements
- Your Development Process will be faster because you do not have to reconsider your next steps while developing. You have done that in the inception
- You will have a good documentation of what you have built
- You can build a timeline and predict when you will be finished
- You can predict what will be finished with this realease
- If you need help you can give parts to other developers. You are prepared if you need help at somepoint.
At the moment I am the only developer in a Project. With this Methodolgy we can keep track of the process and it helps to coordinate my tasks.
You should also definitly use GIT to secure your process.
UPDATE
Planning of the Architecture/Software itself.
First you should check where you want to use the Software. There are numerous possiblities.
a. Web Applications
b. Mac/Windows
c. Iphone/Android etc.
The first thing you have to decide is where is the Software to be used. If you use it on a Mac or Iphone you could work with Apples new Language Swift
If you work on Windows you could use C#
The Andvantages of these languages are that they are optimized for the System and will deliver you more possibilities then Java or C++.
Now this is only one example. If you need a really fast program, where you can do a lot of optimization on the lower Level you could use C++.
If you want an application that you can theoretically use on both System you could use Java. Although from my experience you will have to do lots of modifactions if you want to publish it on multiple Plattforms.
Your coding skills are also important. It depends on what you can code and what your are willing to learn. Each programming Language is optimized for a porpouse. Python, Javascript, Lisp etc. are also really great languages. It depends on what you need.
First Step
Decide the field of operation --> choose the fitting Language
Second Step
Decide if database is needed.
If you have a simple program you may not need a Database. However databases are a great way to perserve data and offer a lot of functionalities.
For local Applications you could use SQLite. It is a simple Lightweight Database which can be accesed from any language.
If you need more database featueres. Make a research on what the databases offer and which one you need.
Third Step
Start building the Application (a skeleton) and test if your Architecture is durable. You may still change your architecture at this point if you encouter that it is to complex.
I will give you a short example for an app:
You want to build an application that sorts all your Mp3-Files in playlists. Basically a better player then Itunes. But you would want it on multiple Systems.
First Step
- File handling (complexity low)
- Multiple Systems (complexity high)
-> node-webkit
You can build cross plattform Applications with node webkit where you can Access folder etcs. The Corresponding programming language would be Javascript while using HTML5,CSS,Jquery etc.
Second Step
In order to organize the MP3s you will need a database. You will only load the links to the files in your folder so the complexity of entries and the load on the database is low. You can use a SQLite DB here. You could use node-sqlite3 whith your app.
Third Step
Build a scratch application in which you can upload a file or load a file in a folder. See if you setting is working. If yes continue with the building of your app. If no start from Step one and decide whats missing.
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 9 years ago.
Improve this question
I would like to create a website similar like imdb.com. Whether imdb.com uses any framework? if so which framework it uses? Otherwise are they developing on their own? Is it easy for a normal PHP developer to create my own php framework?
As a PHP developer:
I have my own php framework, So you can say it's not so hard; But you must first learn how other frameworks work... And decide what your framework need to do... Which design patters you agree with...
Most of big websites didn't use famous frameworks, Or even their own frameworks... Mostly using a plenty of libraries... Because when you use a framework you code faster but you waste resources as RAM, CPU IO/Disk...
A well programmed application is this one that use 100% of its code source, It's good to go OOP, MVC... But not in the way most of frameworks works... This what is life less working time cause a less quality project.
There are two reasons why you would want to create your own framework:
Learning purposes, it's a great learning opportunity because you
will learn a lot.
This one I highly doubt is a issue for you, but
If you believe your framework can be different and better in some
way than those already existing, go for it.
A framework isn't the application, a framework is a tool set that lets you get straight on the application itself, instead of writing a database abstraction layer you learn how built-in in works and writes the busniess logic your application needs.
Developing a new framework is not a trivial or easy work at all. Even for a team is difficult to handle, so be extremely sure you need to create yet another one before starting.
Instead, use open source, well known solutions, so that bugs are likely to be triaged and fixed. There are many which are available even for commercial use. Just choose your favourite one: Symfony, Code Igniter or Kohana or whatever and start building your application on top.
As of IMDB, probably they are using a framework, but there is no way to tell what if any.
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 10 months ago.
Improve this question
I'm a new software architect/lead, coming up with software design for a team of software developers. I'm coming up with the requirement spec, interface header files, and visio software design docs, and build plan, etc.
My question is: what do the rest of the team do during this period? I'm certainly engaging them in the design, but we dont need the whole team actively working on what I'm doing all the time.
Are there any good books for new software architect?
Generally the various stages overlap, so there will be some coding during design etc. There are a lot of things to do besides that. They can be reviewing unfamiliar technology that is going to be used, setting up source control system, reviewing business requirements, reviewing your documents to make sure they make sense and are clear. There is a lot of other work to be done besides programming.
What a software team does while the lead does the design is very different from company to company. On my company we try to work on the design while the developers are finalizing other projects or solving bugs.
Another approach that I've taken when starting a whole new project is to get the developers to work on the design as well - people with a good understanding of the requirements can help you designing smaller parts of the system and writing the specs for them. Others can work on mockups, frameworks. This worked rather well for the small software team I led in a previous job (4 developers in total).
I also found it useful to have other team members research parts I'm unsure of (or even validating that things I think should work will indeed work), such as:
Investigating whether an external API provides the features we need
Writing a small proof of concept or technology demonstrator
Create an API mockup (header file, interface or REST endpoint) to investigate whether the API looks useful.
As other have said, you typically want a ramp-up period during the first part of the project, and through the first iteration. You're planning on building this iteratively, aren't you? Start with a core team (nor more than 3-4 people, since you're going to need to communicate heavily with each other) to help you explore the requirements, get a basic data model in place, identify and setup any frameworks, identify and setup build and test tools. Some coding activities typically take place in the design phase: for UI mockups, run-ahead prototypes of technically sensitive areas (whatever risks you have should be mitigated by explirative coding: be they new technologies, undocumented interfaces to integrated systems, or unstable requirements).
But coders in the design phase should help with the design, in order to get their buy-in, and to help train up the rest of the team during the first iterations. Your role during this is to ensure that the major nonfunctional requirements (e.g. are known, prioritized, are met by the design, and can be tested). You should also collaborate with the project lead or whoever else is responsible for staffing and financing in order to sketch out the iterations and the staffing levels needed. Ensure the solution can be built iteratively, and aim at implementing only a basic structure during the first iteration, both to build confidence, and to eliminate risks. (Sometimes, you can push major risks to the second iteration, and focus the first towards confidence and team building.)
And of course, be sure you are not designing every detail. You should be able to use every design artifact in the next iteration (and elaborate them later as needed). Since design decisions are expensive to change, try to postpone them. However, some influence the entire solution (for instance, the data model, or your approach to security) and absolutely must be at least outlined up front. This isn't waterfall. This is just not closing your eyes and hoping a viable architecture will emerge by magic.
But design proceeds throughout the iterations. It's just that you do less of it as you go along, and with lesser impact on the solution (unless you're unlucky... and then things get expensive).
Stop doing the useless things you do and just start coding with them! ;)
If there is no overlap with another ongoing project, getting them involved as you're doing is great, maybe push it a little further by having them prototype and present the plus and minus of alternative technologies (APIs, frameworks, libraries, etc...) that your project could use.
As a new software architect, I can recommend some books that helped me understand the role of the architect (but of course not to master it):
Fundamentals of Software Architecture An Engineering Approach:
This book gives good modern overview of software architecture and its many aspects, good place to start if you are a beginner or broaden your knowlage.
Software Architecture in Practice:
Explains what software architecture is, why it's important, and how to design, instantiate, analyze, evolve, and manage it in disciplined and effective ways.
Software Architect's Handbook:
This book takes you through all the important concepts, right from design principles to different considerations at various stages of your career in software architecture. It begins by covering the fundamentals, benefits, and purpose of software architecture.
Clean Architecture: A Craftsman's Guide to Software Structure and Design:
Learn what software architects need to achieve and how to achieve it, master essential software design principles and see how designs and architectures go wrong.
Software Architecture: The Hard Parts:
An advanced architecture book, with this book, you'll learn how to think critically about the trade-offs involved with distributed architectures.
Usually there's another project they can work on, but...
I have my team review the project specs/requirements and put together a basic/preliminary structure to get them already thinking through the application and working out specific questions.
When we convene at the table to discuss the plan they already have an idea of what the project is and requires and in some cases, they present questions I may have missed or overlooked.
Although it's too late now, a good way to approach it is to move the architect over before his current project has ended. Start freeing him up at like 25% then work your way up to 75-100% on the new project a month or two before it starts (maybe more depending on how much analysis and customer interaction there is).
On a trivial project (let's say 2 man-years) it might not be necessary, but anything bigger than that can end up in chaos if somebody doesn't at least get the analysis right before everybody jumps aboard.
If your team does not have any other projects to work on, ask experienced programmers of your your team to come up with at prototype so that you can create a requirement doc according to the needs of the client.
Also programmers novice to the technologies being used in the team could utilize this time to familiarize themselves with the technologies on which your team is going to develop the project.
architect != designer
Chances are that all of your developers can help with the design; let them. Architects don't have to be "lone wolves" and do everything themselves. You lay out the guidelines and the principles and the scaffolding, rough in the wiring, and let your developers flesh out the details - whether it is drawing Visio diagrams or building prototypes to mitigate unknowns/risks.
Migrate towards Agile/XP and away from waterfall methods, and you'll find the team a lot more help.
When making the general design, it's very handy to have programmers create proof-of-concepts. Do that especially with parts of the system that could end up being show stoppers if they don't work in the way you plan to do them, so you can think of alternatives, and adjust the design.
That's going to help you to make the right design-decisions before moving entirely into a certain direction.
Just doing a design, and then moving on and start coding is a sure way to mess up a project. You won't realize that your design is not feasible (or just plain sucks) until you're half-way coding, and by then it's too late to make radical changes.
You'll waste time mitigating non-existing problems during the design, and you'll run into unforeseen problems during implementation.
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
What is your method of "mapping out" an idea before creating it?
Say I wanted to take on a big project, for example at the scale of a site like Facebook or MySpace. What planning/design steps should I take before I start the actual work?
For example, should I map everything out page by page (their functionalities, data, etc.)?
For a large project first think of a one-liner to description of your site (try to not use any buzzwords here). Next think of three design maxims (rules your design Should never conflict with). Then draw a few views and think up a few user cases (1 day) then work in code for 2 weeks (this will be a throw away prototype so just work as fast as you can forget about bugs and details, don't worry about code smells or design patterns, just make as much as you can), then revaluate all the steps above and throw away your two week prototype, and begin your project in a serious manner applying solid engineering and design. After a month has gone by evaluate your(team) moral and get feedback. If it all seems to be going ok, continue, you got a long ride ahead, otherwise just give up, do a postmortem, and start over with new goals.
I always start with the user interface design. I figure out what the user should be able to do and what controls I will give them to do it. Once I get that laid out in a way I like it, then I start with the code "wiring".
Make a list of all the features that site have.
Make a list of nice to have features.
Make a list of the weakness of the site.
Order that list and prioritize the items that will be built first.
Identify what will be possible to do and what is not.
Meet with your customer and present these results.
Usually I do a mindmap of
problem I am trying to solve,
translated into exact requirements,
then mapping that to user workflows.
The cross linking features of mindmapping softwares make it lot easy. Since mindmapping is 'kind of freeform', I end up concentrating on the 'task' rather than 'representation' (e.g which type of UML diagram should I use to represent this) ?
Once initial ideas are clear then I can work on project plan, spec/design documents using UML for more low level details. This approach usually works well for me.
To see if it works for you or not, you can use FreeMind (opensource mindmaping software, good but currently limited functionality). Then You can try Mindmanager or iMindmap for mindmaping. Both integrate well with other Office products.
Usually I start out by grabbing my scratchbook and just start writing down what I want as in terms of features, this should be quite detailed. And can be quite messy with every thing scrambled together, if so, when you're done make an 'official version' of you're ideas on paper (REAL pen and paper works best for this in my opinion).
Then I start making some scetches of how the pages would look like, what information it must contain and translate that to a global database design. Then work that global design to a more advanced level where all pages come together, with relations between tables and stuff.
After that I build up the most important pages on a code framework (I always make use of a framework, if you don't then forget the framework part), and by 'most important pages' I mean in for example a blog that would be the posts. After that build the not-so-important pages, in case of a blog that could be an archive of posts.
If you have that done, put the code together with a design, or do that while coding if you do not seperate code from HTML/CSS/JS.
Oh and yes, do NOT expand your first idea along the way. Just write that down and implement that afterwards. So if, in case of the blog again, you think half way you want Youtube tags in you're BB-code, write it down. Add that later, offcourse before you're initial site releases.
That's my workflow, at least a basic basic, basic description of it.
Start with "paper prototypes", i. e. take a pencil and sketch each page very roughly. This lets you start from the user perspective, which I think is a good idea.
You can then use the sketches for a first hallway usability test and later as the basis for "wireframes" you would give a web designer to work from.
If you've gone through the complete site once, you probably have a good idea of what the backend should be able to do. You can now use your page sketches and compile a list of the actions a user can trigger by clicking on things. This is the raw material for designing the server-side API that the frontend can call.
Using the calls that need to be served, you can design the backend: What functionalities group nicely, what data needs to be fetched, what do you need to store between page calls (== Session variables) etc.
In this process, I have fared quite well by postponing technology decisions (frameworks, protocols etc.) and even class structure etc., until I've gone through the whole thing once in terms of "what things should do what to what other things" (I guess there's a better term).
I think I would start with an open-source SNS solution that comes close to what you need and then figure out how to add use-specific plug-ins, modules, and themes that achieve your purposes. There are a lot of em out there. Building from scratch is going to take a lot more effort and planning. Most SNS functionality is not worth re-inventing. Focus on what will make your site unique and build upward toward that.
I'm a fairly visual person when it comes to designing software so I sketch out dataflows, class hierarchies, UI and flow charts on whiteboards and paper first.
Butcher paper and colored pens can be particularly fun to use as it's 3 feet wide and comes in 100 foot rolls. When you've got a design that's satisfying or sufficiently complete, tear it off the roll and pin to the wall. Update as necessary.
That technique has worked for some large refactors as well as new projects.
You could start with something very simple and then add features a little at a time. You may reach a point where you want to start over, but the groundwork you did will be beneficial. Or you can try to do the whole thing at once, in which case you'll need the advice already given in the other replies.
One more idea: Specify those features you are not going to include, and other restrictions. These are called constraints, and are as important as the rest of the plan, as it gives you boundaries so you know when you're done planning!
If you work for the same company as this person, start by getting everything in writing so you aren't the one to take the fall when the inevitable happens...
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
As a long time World of Warcraft player, and a passionate developer I have decided that I would like to combine the two and set about developing some addins. Not only to improve my gameplay experience but as a great opportunity to learn something new.
Does anyone have any advice on how to go about starting out?
Is there an IDE one can use? How does one go about testing? Are there any ready made libraries available? Or would I get a better learning experience by ignoring the libraries and building from scratch? How do I oneshot Hogger?
Would love to hear your advice, experiences and views.
This article explains how to start pretty well.
Your first bookmark is possibly the US Interface Forum, especially the Stickies for that:
http://us.battle.net/wow/en/forum/1011693/
Then, grab some simple addons to learn how XML and LUA interacts. The WoWWiki HOWTO List is a good point here as well.
One important thing to keep in mind: World of Warcraft is available in many languages. If you have a EU Account, you got an excellent testing bed by simply downloading the language Packs for Spanish, German and French. If you're an US Guy, check if you can get the Latin America version. That way, you can test it against another language version.
Once you made 1 or 2 really small and simple addons just to learn how to use it, have a look at the various frameworks. WowAce is a popular one, but there are others.
Just keep one thing in mind: Making an Addon is work. Maintaining one is even more work. With each new Patch, there may be breaking changes, and the next Addon will surely cause a big Exodus of Addons, just like Patch 2.0.1 did.
Another useful tools you might like is WarcraftAddOnStudio which lets you make plugins in the visual studio environment.
I learned the art of add-ons primarily by looking at the code of Blizzard's UI. You can see that code by extracting the default UI or finding a copy of the default UI online. Add-on developers sometimes like to over-engineer their pet projects (who doesn't?), while Blizzard's code is usually pretty no-nonsense and straightforward. In addition, Programming in Lua is a pretty useful (if slightly out-of-date) reference for the actual Lua language.
The best way to start is with the book World of Warcraft Programming. It covers LUA, XML, WarcraftAddOnStudio and the WoW API. The book also has sections on best practices and avoiding common mistakes.