I didn't really know where to put this so I'll post it here.
I've been programming Java for a while now and I want to make something to show/improve my experience.
I'm looking for a big project so when I get a job interview, I can show them something.
The problem is that I can't find anything that I can use during a job interview.
I only use Java SE and Java Fx, not J2EE.
Any suggestions are welcome.
Thanks in advance,
Here's a nice, small project. Create an application that can list the contents of a simple table that keeps track of users, and allow the user to select a record for modification. Use MVC methodology, not the event-driven drivel the M$ pushes. When you get done with that one, design an application that actually does something, like a means for people to enter the time they start a new activity by pushing a button. This will take you far longer than you think, but it will force you to learn all the core technologies.
Thanks for your reply.
I've been pogramming in Php for a few years so I know the web basics.
But I don't really understand the project you're suggesting.
Can you explain it a bit more?
In my experience most of the time, interviewers are testing on the concepts on the project you've done. Like OO concepts and technologies related to different architecture I guess. So better to be in a level on those areas, to satisfy the panel.
But the problem is that I don't really have a project I can show.
In my opinion, interviewers won't choose someone who can't show anything.
True, but useless if you don't know how it related with technical stuff. Anyone can copied a project somewhere and show-up in the interview.
Originally Posted by bubbless
First thing you have to do is, think about a product, an ideas of different stuff. I don't think anyone can give you an idea straightly here. Just think about a simple one first of all lol. Then let us know, and we can discuss about about that topic, means your idea builds on lots of experience of other members. :)
Back to the project I suggested: I have found that I created "master table maintenance" applications with every new system I built. They are unavoidable, since every system has master data. I have also found that these applications are often left out of systems, simply because no one bothers to write them. Master data is entered using interactive SQL or some sort of table editor. Even large applications, such as order entry, are really just massive master table applications that operate on a number of tables at once. These applications also use the a range of technologies and give you a great opportunity to practice object oriented and Model-View-Controller design.
I suggest starting with a relatively small table, such as user definition for a stand-alone system. First, you need to do the basic analysis and design. What are the attributes of a user, and what methods operate on those attributes? One good practice is to "deactivate" master table rows, rather than deleting them, so include a status attribute. Good table design also includes columns for row created, created by, last modified, and last modified by. You might also want to include a "row in use" scheme. I use a timestamp that says the row is "in use" until the specified time, usually 5-10 minutes. After that time, another user can reserve the row, and the previous user loses their reservation. However, if no one else wants the row, the reservation remains valid indefinitely. A user cannot update the row without a valid reservation. And, I forgot to mention that the use of a "surrogate key" is always a good idea.
Once you create a table, you should design an object that represents the table row. The object should be able to instantiate itself from the key, validate its contents, and save its state back to the table if the contents is valid. Another useful object is one that retrieves a list of rows, based on criteria. These objects form your data model.
On the front end, you need UI objects that can display a list of objects, provide add/update abilities for a selected object, and perhaps a way to enter criteria for what should be included in the list, such as displaying only active rows. This defines your view.
Each view object should stand alone and have no direct connection with the model objects. A controller object is the entry point for your application. It creates the view and determines which view object displays, based on user actions. It also moves data between the model and the view.
In Java, keep the view and the controller "loosely-coupled". That means the connection between the controller and the view should be as small as possible. AbstractAction is a good means of doing this. Have the view listen to its own events. Have the controller pass each view object a specific list of AbstractAction subclasses, each representing a specific action. Note that AbstractActions can be specified on things like JButton, so you don't have to listen for events at all.
As far as moving data, don't let the view objects and the model interact directly. Ideally, the view should specify setters and getters for the information it needs, as does the model, and the controller should handle shuttling the data back and forth. This is an enormous waste of time, right up to the point where your application becomes complex enough to actually do something useful. If you do things right from the start, you will in time see the wisdom of this approach, when more than one application uses the same model components. This is very different from event-driven design. I've done both, and MVC is superior for everything but trivial applications. In addition, once you understand MVC, it takes little extra effort and time. The real time and effort are in learning.
Once you have a user table, you will want to have a roles table, and then a table to assign roles to users. Next, an applications table, and a table to link roles to applications. Then you can think up a simple application. My first Java application was request tracking. It ended up with different levels of authorizations (managers, VP's, IT, administrator), list filtering that was role driven, and simple reporting. Do a project like that, and you will have something to talk about during an interview, where you can discuss concepts in the context of your implementation.
Hmmm, good idea. Best thing it comes up with your own idea. ;)
That's quite a big idea, Steve.
However I doubt I am getting it right.
Do you mean something like a UI to create/edit/delete rows and tables in a database?
If you're familiar with Php and MySql, is it something like phpMyAdmin?
If it is, that sounds like a great project.
About the MVC pattern, I'm familiar with that and I've used it several times.
Eranga, what do you mean by the technical stuff?
Actually as I said in may last few post, before you done the project you must have the complete idea about the technologies you used there in the project. In my experiences interviewers not just ask to show your project, how it works. Normally what they do is, while you are going through the project, if anyone in the panel interest on any part of the project they disturb you and start to ask questions.
First question is, how that idea comes into your mind. If you say the idea given by one of my friends, it's the end of independent of your works. Actually a bit not whole. Because in industry team works plays a major role.
The next question is what's the technology you used. Means that, need to explain from the programming language you used to design pattern and all.
Those two questions are crucial in an interview. :)
I get your point, but when you only got very small things to show, there's not much to say about it.
How about getting involved with some open source project... there's plenty of those... you'll probably learn a lot and would sound good at interview time.
Agreed up to a certain level. Sometimes small thing make a big difference. Depends on the way you workout. I've seen that lots of people try out that, do very simple things very hard way. Some people success in that way. ;)
Originally Posted by bubbless
Ok, but still, I'd like to make a big project first, so I have something to show.
I was thinking about an rpg game.
It's also a good project to use OOP correct so I'll probably take that one.
Okay, you can take whatever. Give a try and see. We can help you. Start from the project proposal, design and so on...
Sorry I took so long to get back. I call these things master table maintenance programs. Yes, they *only* provide filtered lists of rows, allow a row to be selected, and then display and allow modification of the contents of the columns. Conceptually, they are quite simple, but the reality is that they take quite a bit of work to get them right. On the other hand, this is a manageable project, and you will have plenty to talk about when you are done, from how you handled your HTML, etc, to the controller design (Struts, Spring, whatever), to the model design, to JDBC, SQL, and the database. If I was hiring
someone right now, these are the sorts of things I would want to hear about.
Once you have the pattern down, you can then build a system in which the user can actually maintain the files the system uses.
As far as an RPG game, that is not something I would be interested in hearing about if I was hiring a business programmer...
I like that Steve, that's the way to find the best. And also more likely, I want to test analytical knowledge as well. It make big difference in designing models and stuff.