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.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
My company is in the infant stages of looking to building a team to develop a new platform to replace our existing system. UI/UX is extremely important since there are several thousand users. The current system is built in PHP with Zend.
I have been doing a lot of research and have thought about Yii with DoJo or something similar. I have also looked at the ZK framework if we decided to go the Java route. Whatever we choose the framework has to talk well with linux and be able to perform low level system operations like creating/updating files, etc.
At the end of the day I know very little about Java but the more I look it seems like all of the clean web applications are running Java.
Am I missing something here or am I on the right track thinking:
PHP = easier to train and hire people. Harder to get a rich UI
Java = harder to train and find developers. Clean UI more easily obtainable.
Choosing Java over PHP isn't much about a clean UI, is much more about the ability to grow in both size and complexity.
Don't get me wrong, I'm aware that there's a lot of big complex systems running fine with PHP, it's only that I find that Java has more support built in the platform for scalability.
You can have a clean, rich UI with both PHP and Java.
PHP - Easier and faster to get started. Harder to get around performance and scalability issues, even with proper knowledge.
Java - Harder to "get it right". If everything is done properly you'll reach performance problems later than with PHP... but with the proper knowledge it will be easier to find solutions.
But, as far as UX goes, you should go with what your developers are most confortable with. If the UX and backend logic are decoupled you can treat them as separated problems.
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 9 years ago.
Improve this question
I'm in the process of putting together a year long PRACTICAL course (not academic) to produce Java programmers who can be productive from day 1. I've found that often computer science university graduates know all about the Fourier transformation, but as interesting as that may be, doesn't help me integrate them onto real life projects.
Apart from obvious programming I have thought of a number of other topics
Testing
Continuous integration
Source control
What to do if you have a problem (e.g. this site)
Agile and other methodologies
Documentation
If you can think of any others please let me know.
debugging techniques
The theory that's probably necessary:
How to sort an array with something that's not O(n^2)
The very basic data structures; array, list, tree, stack, queue, heap are the first to mind.
If not how to write them, then absolutely why you'd use a tree over a list over an array, or vice-versa.
The practical knowledge that's also necessary:
The book The Pragmatic Programmer covers most of what you're asking here.
Eclipse. How to work a debugger. How to work a profiler.
Ant.
Some basic web framework; Struts, Spring, etc.
Apache Commons, JAXB, a SOAP library, a REST library.
How to read bad, uncommented code. How to refactor it bit by bit to be maintainable.
What a good comment is.
HTML, CSS, JavaScript, JQuery, in that order.
Validators (W3C), formatters (Jalopy), checkers (PMD, FindBugs).
How to use a piece of Bug Tracking software; how to write a good bug description, how to explain what you've done to fix it, and how to handle user expectations.
Actually, that deserves it's own line; how to handle user expectations and conflicting timelines and goals.
You need to teach them how to:
Read other people's code for comprehension
Work within a legacy code base (the steps, from reading to building to running tests to modifying)
In addition to what you have, working in teams on a mid-size project. This will also (hopefully) help them see the benefits of source control, testing, and documentation.
Another answer mentioned debuggers. In the same respect, I would also give an overview of profilers.
One thing I wish my professors covered more in my programming courses was using IDEs effectively. My professors mentioned that we should check out Eclipse, but never really taught us how to use it to its full potential. Even now I frequently find new features of my frequently used IDEs that save me a LOT of time doing trivial tasks.
Once you get past the skillset needed to be a coder, I think the next step is learning to code smarter and not harder.
Code reviews.
Receiving and giving code reviews is not very easy and quite often people get annoyed quite easily, especially the one whose code is being reviewed. But it is very useful to be forced to take on criticism and to explain your decisions. For the reviewer it requires you to read other people's code and to be able to point out the problems in it and of course to describe why you think the developer has done something wrong.
I'd dedicate a fair chunk of time to UML and pseudocode design. Writing a quick spec or even a few lines of pseudocode takes some practice and has tons of benefits.
Another thing I'd recommend is build procedure. While this stuff varies from place to place, a primer on things like Ant, continuous integration, etc would be great.
Sounds like you want to teach software engineering more than Java. You have covered most of the main topics however, I would suggest the following as well:
Software Architecture: There is design and then there is architecture. Understanding how different components will/should interact in a project is important
Requirements gathering: Getting the actual spec from the "business owners" is a valuable skill. Too many people think that actual requirements for a project will just be given to them.
JDBC/Databases: You have to touch on databases if they are going to be useful on day 1.
MVC: I don't think it is important to go through all design patterns however, it is definitely worth mentioning MVC. It is an incredibly important pattern for Web development and really can be applied to most anything.
1 year is not a lot of time to turn someone into a software engineer. There is a lot of practical experience that has to be developed and generally speaking, that is why a Bachelors is 3-4 years.
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 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.