Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I received an exercise: control a chess game.
No AI, just a human-vs-human chess game.
This is the first full-blown project I'm developing.
I have 3 weeks, during which I have about 2-4 hours every day.
I'm developing alone.
How do you suggest I manage the time and the flow of development?
Thanks,
Nur
Before delving into details, develop the logic on paper and start coding a simple prototype that includes the basic and core functions, no fancy things. Then, incrementally develop, add new features.
I strongly suggest you write up a few use-cases before you start.
If you're new to java-programming, I furthermore suggest that you make sure you know how to implement each part of the application. Figuring out how to, for instance, draw a piece on the screen for the first time, is not a good idea to do during the actual project.
Writing up the algorithms for deciding which moves are legal and so on is probably not trivial, but it's not something you'll get stuck on. Using custom components and user interaction in Swing may be though. So make sure you know how to solve such problems before you start.
I would suggest TDD (Test Driven Development), that advocates writing test before writing the code. I did a similar project a few years back, and the test saved my ass more than once.
It is an iterative process, which advocates making small steps and gradually building the end application.
1) Start with writing the requirements for some subset of the problems, such as moves.
2) Make some test cases such as 'unit should be able to move three blocks' or 'unit should not be able to move, when it is the other players turn'. Remember to keep focus, which means keep changing the same problem domain until it works.
3) Fake it till you make it, i.e. fake the tests to return true or false or some other passing value.
4) Make a small change, see the tests fail and then implement the given problem correctly.
5) repeat
The main deal is to keep it simple and take small steps.
As for the design of the code, consider the FACADE pattern, and of course the other more trivial ones as State, Strategy and AbstractFactory.
Don't waste any more time here and start cranking!
What will be the output of your project. Will it be a full fledged game which handles all cases and will be used by many people throughout the world.
I suggest start with getting detailed requirements like
Whether users will be able to edit the chess board theme.
Whether you will provide undo features
Whether you will provide sound etc
Once you get this part done you must be able to get sufficient information on what needs to be done and then you can plan accordingly.
Writing the core logic for the game can be pretty much done anytime as it wont require much changes once the other requirements are clear.
If it's just yourself, note down some high level objectives of what you want to do, quickly estimate the work to get to step one and then do it. Reassess once you get to that point and then repeat for the rest of the steps.
You've only got three weeks, you probably don't have much time for setting up a whole project management structure.
Choose a software development method and try to stick to the main principles. In your case I'd have a look at scrum with a focus on solo scrum. Here is a guide but there are more shortes explantions on the web. You don't have to master the method but it's elements (backlog, sprint, burndown) are valuable.
in-step scrum edition is a very nice tool for this method.
And don't forget to build a good software development environment (SDE), at least a good Java IDE and a version control system (subversion, mercurial). Don't forget implementing a ot of tests (saves you a lot of time at the end of the project) and I suggest setting up a continuous integration tool (hudson CI). (if you use scrum, one of your first tasks in the project could be setting up the SDE)
1- bring a pencil and some papers, start writing the big steps of your project and begin detailing every step (actually every step will generate new steps) so you will end with something like tree ending with the needed algorithms..
2- start coding!
Related
I started a job as an appdeveloper for android. After a week they figured that I'm not fast enough getting the apps ready so the fired me and offered me an internship, for free.
I'm wondering how I can get better fast. Should I read more (I'm missing architecture stuff I think)? What should I read? should I just start coding stuff, or should I do a course of some sort?
I'm reading design patterns from head first. Will Java design patterns help me with Android or are they not applicable on android. Basically I'm at home reading android stuff. The company said they would take me back when I'm good enough so I need to get better quick.
Best way to learning ( imho ) is by looking in to already coded project and disecting them. Try to understand how the program is made up. Then work on some tutorials and expand then!
Resources:
Java: http://download.oracle.com/javase/tutorial/java/index.html
Android tutorials: http://p-xr.com
I assume you are the only developer in a very small company. If I'm wrong and there are multiple developers then they should be doing design and architecture and you shouldn't need to worry about that--just code the sections they give you to code.
So the rest of this is based on the assumption that you are the sole developer.
Don't worry about architecture or design or anything--Get a GUI together as fast as you possibly can--it's all about what you can show. Even if it has nothing at all behind it, it's visible progress.
A well architected solution will save you bunches of time in the futre, but from the sound of it you don't have the experience, and also a well architected job is front-loaded.. a lot more time spent before you can show anything. Doesn't sound like that will make your employers happy.
I'd actually spend 2 or 3 hours some evening researching some of the "Project Management and Design portions of XP (you may have to do this on your own time at first--but then if you're getting paid $0 all your time is your own time right now)
XP is all about your process being transparent to your customer (in this case your customer is your employer). This allows them to understand why something might take time and it actually allows them to make decisions on the fly to correct problems or speed the process by eliminating features.
I'd start by writing down each task on a piece of paper. Each of these tasks should take a couple hours to a day or two to do so make them pretty fine-grained but don't write down a time estimate, instead when you are done with the cards go through them and rank them all in difficulty 1-5 (The purpose becomes clear when you see how XP does time estimations).
Then you start interacting with your employeer---they choose which tasks they want done for the day/week. You do them.
As you are executing tasks you may encounter new ones or have to break some up. This is expected--make more sheets of paper. If your employers want to know when it will be ready, look into how to do burndown charts and time prediction. In XP this practice does a good job of taking into account the fact that programmers suck at estimating time (It uses your history and the difficulty 1-5 ranking to determine how long a "2" actually takes you to do.
Soon after implementing this practice, decide on what metrics they want you to maintain in order to get paid, or see if they want to pay you per task.
On the other hand they are only treating you like that because you let them. You're fired now, start looking for another job. If you find one, just walk away.
Best for learning is doing. All reading will get yo nowhere if you don't practice.
And the design pattern may help, but much of the classical wisdom may not directly apply - if only for the fact that the devices have limited memory.
Take the JavaBeans approach, where a bean has to have a getter and setter. On Android (before 2.3 iirc), this had a negative impact on performance, so that making fields public and directly using them is preferred.
To learn, take an open source project (e.g. my Zwitscher app), use it, try to find out what you want to improve and improve it.
Firstly, make sure that your employer was justified in his reasons for firing you. Some of the questions you should be asking them are:
- Were the deadlines not respected? In this case, if you did give them timelines for completion of phases of your work, then you may need to look at improving your effort estimation. If they gave you timelines, see if they were reasonable
- Were features added to your work on an ad-hoc basis? Many times I've found that a freeze on requirements is consistently broken
- If you are slow and haven't picked up some of the basics, then come up with a sample application that closely resembles your employer's application, and DO it. Use SO, developer docs and books to clear doubts and hone your skills.
Best of Luck with Programming :)
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
what is the best way to understand a big company project in java?
There's a nice podcast/interview with Dave Thomas ("The Pragmatic Programmer" Dave) about this topic, here.
He calls it "software archaeology".
For many different reasons organizations frequently lose control of their code bases. Knowledge gets forgotten, people leave. One could very easily mistake the code base for an archaeological concern were it not for the fact that mission critical applications built upon it keep chugging along until something needs to be modified or enhanced and then suddenly you have a vat of source code that no one understands but that has become the most important thing in the world overnight.
There are very few short cuts for coming to terms with big vats of code. Generally, one has to balance the quest for "understanding it" with the pressure to make pointed pragmatic changes to "complete the mission".
You'll never know every line of every piece of code at a company. What you CAN do is understand the classes, what they do, and how they relate to each other.
Start by getting the most basic understanding of the way the code flows from a class perspective focusing on the large classes that do that majority of the work. Once you understand what's happening there start focusing on smaller classes. Keep this up until you have a pretty good understanding of a handful of classes.
Additionally you can break it down in to common programming tasks that your company has. Once you have a list of these research what's involved in implementing each of them.
The final thing is just experience. You can study the code as long as you want, but there's no substitute for playing with the actual code. Writing programs, testing things out, and looking at how existing code runs are the best way to learn a new system.
Start writing unit tests - you do something useful (which will probably earn you more time to understand the code) and you get an in-depth look into the functionality. Also, start asking questions when they come up during that process, you will be able to ask very specific questions and you might impress your colleagues :)
Few places I often start from is the build/package/deploy scripts and configuration files - depending on the size of the application we are talking about, they can tell you a lot about the internal structure, external dependencies and highlight things to dig in further.
Next you can use code coverage tool and record the coverage for a simple scenario, which points roughly which areas are performing it. A variation of this is running under tracing profiler. Heap dumps are also useful for getting an idea of the basic data structures.
Finally, look application logs during various scenarios, though these are usually too much information and you need to know what are you looking for.
All these should give you a good idea of the overall application. After that, you need to fire up a debugger and start poking in the code. Ask your colleagues for their favourite breakpoint locations - usually everybody has some.
In case you are doing Java or C#, make sure you know your IDE and how to use find-usages. There are further more advanced tools for static analysis and comprehension like Structure101 (my favourite), SonarJ or LattixDSM.
Some UML reverse-engineering tools can generate class diagrams, but usually they create too much noise and doing the pruning manually assumes you can discern the important from the unimportant (which usually is not the case with new codebase). If you get one of these, I recommend starting with essential class and using the "Add dependencies" functionality to incrementally explore the application.
Take a simple first task, and don't rush anywhere. Look around, use the time to learn and understand the environment. Examine the call stack, use a debugger. And when you have a solution, ask your peers for a code review, and learn from them.
Then take another task, and another one, and another...
You'll get there soon :)
Documentation my friend, look for manager patterns seek the jsp play with the code dont be afraid to make small changes and see what happens, understand the logic and the building blocks, stay way from companies with poor documentation.
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 5 years ago.
Improve this question
Most of the time I have been programming little apps either for myself or for the benifit of learning. Now that my programming skills are considered somewhat intermediate, I was wondering how I would tackle a large programming project.
Lets suppose I wanted to make an application that has a lot of features and is intended for the use of others and not just myself; how do I go about planning for such projects?
Do I just jump in and start coding the thing or is there some sort of recommended process?
Thanks in advance :D
Although Steve has a good recommendation, I think that answer is probably a bit beyond where you are at.
The "simplified" version of how to go beyond what you've been doing is:
gather requirements from the users. Write them down in terms of required functionality.
Do simple screen layouts. The main part here is just to get functionality grouped into the right areas.
Build a data model
Build the actual screens and tie them to the data model.
Iterate with more features.
At each point stop and do a reality check. For example, do the screens make sense? Is the information organized in a good way? What areas might you have a problem in? etc.
Above all, stay in communication with the people that will actually use this product.
Also, their are two keys to a successful project. The first is to break it down into manageable portions. In other words break it up so that you can deliver each piece quickly, call that piece done, and move to the next. This will help you to stay focused and not get in over your head.
Second, work with what you know. When moving up, refrain from taking this as an opportunity to expand your coding skills. Instead, your focus here is going to be on learning project management.
After you've done one or two iterations of this, then look into the various software development methodologies such as scrum, waterfall, etc and see what they have to offer you.
Good luck!
Some of the things your going to want to look at is a tool chain including source code control, unit testing, documentation, automated builds, continuous integration, bug tracking etc. Programs at this level become very complex very quickly. So you definitely don't want to just start coding. you are going to want to develop a list of things the program should do. Then refine this list to must haves, would be nice and in a perfect world. From this list you can start designing a database schema, screen designs, and a class structure (assuming OOP).
This book is based on web applications, but much of it applies equally well no matter what language you are working with:
http://www.amazon.com/Developing-Large-Web-Applications-Producing/dp/0596803028/ref=sr_1_1?ie=UTF8&s=books&qid=1273632445&sr=8-1
You will also want to think about communication, most applications at this level of complexity are not the product of a single person, but rather a team. As a result effective communication and teamwork, become very import considerations.
This is by far not everything you will need to create a successful product, but should start you in the right direction.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
We have a Java Swing application which is basically a two tier application - An UI layer which connects to a database and which does some heavy-lifting across both the layers.
We have been observing some performance issues with the application and are looking for strategies to load test the application.
Basically our goal is to launch multiple instances of this application and simulate a load which would help us figure out these performance conditions in a test environment.
I am looking for suggestions on how we can do this:
Any tools that you would recommend?
Approaches (Virtualization? / Citrix)
Please let me know if you need further information to help you answer this question.
OK, I was pretty sure you had JTable.... This is probably a HUGE part of the problem.
But it can be solved, I don't know how to copy the link for a previous answer I made but basically for financial data and JTable, you want to read the following...
Sun has a tutorial precisely for this purpose called the "Christmas tree" that specifically address the "frequently updated data like financial ones" Swing/JTable slowness problems.
Here you go, "How to create frequently updated JTable that perform well":
http://java.sun.com/products/jfc/tsc/articles/ChristmasTree/
One of the thing that I found really amazing was to constantly display the memory used: you may want to do that.
You'll be amazed at how much needless crap is generated by a default JTable, slowing everything down and making of course the GC trigger way more often than it should: needless objects creation, needless graphical redrawing, etc. It all makes for an application unusable, even on very fast setups.
So start implementing all the tricks given in the link I gave you and you'll see that everything shall run much smoother. I'm now running very complex and "constantly updated" JTable and all is fine now :)
Basically, besides for the simplest case and tiny amounts of data, the default JTable implementation is really terribly bad.
Once you start working with "real world data" (like financial stuff ;), you need to follow the steps outlined there if you want your JTable to perform well.
I'm not saying it's your only cause of slowdown, but I've been there and implementing most of the hints hinted by Sun in that article greatly helped. Actually I went from an unusable application to a very enjoyable one.
Before you go and work on performance tests for the app, you should ensure that you are following the correct threading guidelines for Swing applications. It is important to keep your database access in a separate thread from your GUI painting. See this link for more information.
When it comes to any sort of testing, performance included, it is much easier to test the application when the UI and the business logic are separated. You mentioned that you have a UI that does some heavy lifting and that is generally not a good thing. You'd like to be able to test the application just using its APIs (using the APIs the UI calls).
When performance testing the entire application with the UI, there are some performance testing tools you can use to help. JMeter is one that comes to mind, and some Google searches will surely find others.
It really makes testing easier to modularize the code and separate out the UI and business code, so it will be easier to isolate the components and determine where your performance bottlenecks are. If most of the logic is outside the UI, you can use standard Java profilers as well to see where most of the time is being spent.
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 4 years ago.
Improve this question
It's been mentioned to me that I'll be the sole developer behind a large new system. Among other things I'll be designing a UI and database schema.
I'm sure I'll receive some guidance, but I'd like to be able to knock their socks off. What can I do in the meantime to prepare, and what will I need to keep in mind when I sit down at my computer with the spec?
A few things to keep in mind: I'm a college student at my first real programming job. I'll be using Java. We already have SCM set up with automated testing, etc...so tools are not an issue.
Do you know much about OOP? If so, look into Spring and Hibernate to keep your implementation clean and orthogonal. If you get that, you should find TDD a good way to keep your design compact and lean, especially since you have "automated testing" up and running.
UPDATE:
Looking at the first slew of answers, I couldn't disagree more. Particularly in the Java space, you should find plenty of mentors/resources on working out your application with Objects, not a database-centric approach. Database design is typically the first step for Microsoft folks (which I do daily, but am in a recovery program, er, Alt.Net). If you keep the focus on what you need to deliver to a customer and let your ORM figure out how to persist your objects, your design should be better.
This sounds very much like my first job. Straight out of university, I was asked to design the database and business logic layer, while other people would take care of the UI. Meanwhile the boss was looking over my shoulder, unwilling to let go of what used to be his baby and was now mine, and poking his finger in it. Three years later, developers were fleeing the company and we were still X months away from actually selling anything.
The big mistake was in being too ambitious. If this is your first job, you will make mistakes and you will need to change how things work long after you've written them. We had all sorts of features that made the system more complicated than it needed to be, both on the database level and in the API that it presented to other developers. In the end, the whole thing was just far too complicated to support all at once and just died.
So my advice:
If you're not sure about taking on such a big job single-handed, don't. Tell your employers, and get them to find or hire somebody for you to work with who can help you out. If people need to be added to the project, then it should be done near the start rather than after stuff starts going wrong.
Think very carefully about what the product is for, and to boil it down to the simplest set of requirements you can think of. If the people giving you the spec aren't technical, try to see past what they've written to what will actually work and make money. Talk to customers and salespeople, and understand the market.
There's no shame in admitting you're wrong. If it turns out that the entire system needs to be rewritten, because you made some mistake in your first version, then it's better to admit this as soon as possible so you can get to it. Correspondingly, don't try to make an architecture that can anticipate every possible contingency in your first version, because you don't know what every contingency is and will just get it wrong. Write once with an eye to throwing away and starting again - you may not have to, the first version may be fine, but admit it if you do.
I also disagree about starting with the database. The DB is simply an artifact of how your business objects are persisted. I don't know of an equivalent in Java, but .Net has stellar tools such as SubSonic that allow your DB design to stay fluid as you iterate through your business objects design. I'd say first and foremost (even before deciding on what technologies to introduce) focus on the process and identify your nouns and verbs ... then build out from those abstractions. Hey, it really does work in the "real world", just like OOP 101 taught you!
Before you start coding, plan out your database schema - everything else will flow from that. Getting the database reasonably correct early on will save you time and headaches later.
The main thing is being able to abstract the complexity of the system so that you don't get bogged down by it as soon as you start off.
First read the spec like a story (skimming through it). Don't stop at every requirement to analyze it right there and then. This will allow you to get an overall picture of the system without too many details. At this point you would start identifying the major functional components of the system. Start putting these down (use a mindmap tool if you like).
Then take each component and start exploding it (and tying each detail with requirements in the spec document). Do this for all components, till you have covered all requirements.
Now, you should start looking at relationships between the components, and whether there are repetitions of features or functions across the various components (which you can then pull out to create utility components, or such). Around now, you would have a good detailed map of your requirements in your mind.
NOW, you should think of designing the database, ER diagrams, Class Design, DFDs, deployment, etc.
The problem with doing the last step first is that you can get bogged down in the complexity of your system without really gaining an overall understanding in the first place.
I do it the other way around. I find that doing it database-schema-first gets the system stuck in a data-driven-design that is difficult to abstract from persistence. We try to do domain model designs first and then base the database schema on those.
And then there's the infrastructure design: the team should settle on conventions on how to structure the program first and foremost. And then we work together to agree first on a design for the common functionality of the system (e.g., things everyone needs like persistence, logging, etc.). This becomes the framework of the system.
We all work on that together first before we split the rest of the functionalities amongst ourselves.
It has been my experience that Java applications (.NET also) that consider the database last are highly likely to perform poorly when placed into a corporate environment. You need to really think about your audience. You didn't say if it was a web app or not. Either way the infrastructure that you are implementing on is important when considering how you handle your data.
No matter what methodology you consider, how you get and save your data and it's impact on performance should be right up there as one of your #1 priorities.
I'd suggest thinking about how this application will be used. How will future users work with it? I'm sure you know at least a few things about what this application needs to handle, but my first advice is "think of the user and what he or she needs".
Draw it up on plain paper, thinking of where to section off the code. Remeber not to mix logic with GUI code (common error). This way you will be set to extend your applications reach in the future to servlets and/or applets or whatever platform comes along. Section in layers so that you can respond to large changes faster without rebuilding everything. Layers should not see any other layers than their closest neighbouring layers.
Begin with true core functionallity. All that time consuming fluff (that will make your project 4 weeks late), wont matter much to the wast majority of users. It can be added later once you are sure you can deliver on time.
Btw. Even though this has nothing to do with design I'd just like to say that you won't deliver on time. Make a realistic estimate on time consumption and then double it :-) I assume here that you will not be alone in this project and that people will come and go as the project progresses. You may need to train people midway through the project, people go on holiday / need surgery etc.
Split the big system to smaller pieces.
And don't think that it's so complex, because it usually isn't. By thinking too complex it just ruins your thoughts and eventually the design. Some point you just realize that you could do the same thing easier, and then you redesign it.
Atleast this has been my major mistake in designing.
Keep it simple!
I found very insightful ideas about starting a new large project, based on
common good practices
Test Driven Development
and pragmatic approach
in the book Growing Object-Oriented Software, Guided by Tests.
It is still under development, but first 3 chapters may be what You are looking for and IMHO worth reading.