We Keep Coding

How to be proficient and efficient with NetBeans? [closed]

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
Dear people of stackoverflow,
I am learning to code Java and recently switched from programming in text editors and compiling in terminal windows to an actual IDE, NetBeans (I know, I'm a dinosaur. I inherited the habit from C++). The point is, I'm really lost.
I installed NetBeans because I saw some friends from school open the application and write about 50 lines of code in half the time it took me. I'm guessing they use some sort of templates or customized settings.
I would really appreciate it if you could shed some light in the subject, because I want to be as fast and efficient as possible when coding, especially when dealing with really long assignments.

This isn't something that can be quickly answered in this format.
The main advantages are:
Intellisense/Code completion (start typing code, press ctrl-space)
As-you-type error checking and reporting with automatic fixes in some places
Code generation (source->generate code)
Navigation (go to source, go to decleration, find references, etc).
Integrated debugging
Refactoring (renaming variables, methods and classes; introducing classes and methods; etc).
Try all of those things to get you started but there are many many more.

There's not going to be any one silver bullet; this is the accumulation of many small efficiencies, including keyboard shortcuts, advanced features, templates, etc.
You should take a closer look at what your friends do, and each time you see them doing something you don't, ask them about it. Better yet, each time you come across a task that intuitively seems like there should be a better way to do it (e.g. typing a similar pattern over and over), google around and see if there is a better way. There likely is!
For a more rigorous approach, of course, you can read the NetBeans manual end-to-end in order to get a comprehensive understanding of its features. I've never done that for my IDE of choice, though.

Ok, you have an IDE (that's good!). With it you can make a lot of shortcuts for developing. Here some tips:
You can create a project using a template by going File -> New Project -> <LANGUAGE> -> <TEMPLATE>. This template will autogenerate a basic source for what you want.
You can put breakpoints in any place only clicking in a line number.
You can debug by going to Debug -> Debug Project
You can auto-generate a double-clickable .jar by going to Build -> Clean and Build
You can run a console program directly in the IDE, by using Build -> Run Project
You can even install plugins for extending the IDE's functionality
There're lots of things I'm not telling you, cause it's a long list. You can see NetBeans Documentation for more info.

Eclipse workspace location - best practice [closed]

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 check out a java project to a folder. Someone told me that I shouldn't point the eclipse workspace to this directory.
Is there a best practice for this? Should you use the svn checkout dir or a dedicated one?
And why?
Thanks!

The reason why you shouldn't point your workspace to your existing files is because you want to keep the actual source files separated from your workspace settings.
The workspace that you're using has nothing to do with the code that you're writing so it's generally advised to keep them separated.

You shouldn't point the workspace directly to the directory of the checked out code. Say you have your workspace located at C:\workspace, then I would check out the project in C:\workspace\project.
On the other hand, it doesn't really make a difference of you would check out your code to another location, say C:\projects. Anyway, I don't see any bad practice with either way to do it.

I have seen, read and thought of different ways of using workspaces (per project, per application (multi-asseted or not), per program language, per target (web-development, plugins,..), and so on) and I am still doubting what the best approach is.
Can anyway give an elaborate, but not a page long insight into this?
This involves a lot of sub-questions, so to speak, and I don't know all the specific sub-questions I should ask, because I am not sure I don't know all the aspects of eclipse (and workspaces), but I'll try to give an example of what I am looking for:
What for?
What did eclipse development mean it to be used for?
What do other/most people think?
What do you think?
... ?
Why?
Are there configuration conflicts vs. sharing merits?
Any filespace reasons?
Performance?
... ?
Oh, and I am speaking of the minimum use case for a developer that uses different languages and protocols, and NOT necessarily all of them in one project (E.g. php, javascript and xml for some projects, C# for others, java and SQL for still others, etc..)
So you can choose any directory which you think is safe to keep your work. The main idea is to keep your all projects together.
Hope it will help you.
Or refer Create a new workspace in Eclipse

Managing my first project [closed]

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!

how to choose an open source library? [closed]

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
when every one of us program in java he would need a library (some jars) to complete his work .
so when this programmer find some libraries he need . how he can find the best of these libs ?
thanks.

I don't program in Java much but I do need to hunt down libraries for C++ and Python, which are my mainstays.
I think some criteria you can apply to stuff you find on Google or community sites like SO and java.net include the following:
How well documented is the project? Is it just API documentation? Does it have samples? Are they documented or just spat out? Are there tutorials?
When was the last stable/unstable/testing release? Do version control logs indicate activity in the project? (Google Code projects have a indicator on the right side of the page which shows project activity) Are their mailing lists active? Do a lot of people ask questions and questions get answered? Are developers talking on their mailing lists?
Is the API to your liking? This is both a matter of personal preference and objective measuring. As an example, for C++ GUIs, some people like the API of wxWidgets more, whereas some people like the API of Qt more, and there are people who are more productive in each, but there are also good reasons to believe objectively why one is better than the other API-wise.
Is the project "famous"? This is kind of iffy because it relies on groupthink, but there is some merit to considering projects based on how "famous" or "well-known" or "widely-used" they are. It helps because this is normally an indicator of reliability (emphasis on normally, i.e. not always). The communities will probably be more active and knowledgeable. You can tap onto existing programmers who are already probably familiar with these APIs and hire them or recruit them, etc. For example, I suppose that other than being generally quite good, a lot of people go for Lucene as their text search system because it is very widely used.
How mature is the project? Is it in alpha? Beta? Pre-release? Sometimes you find a library you really like but it's very raw. Depending on the nature of your project, you may want to reconsider using it.
All that said, generally good places to find good Java libraries are probably projects from Apache and those published by Google.
This is all I have for now. Take them with a pinch of salt. If I have anything else to add I will edit this post.
Hope this helps!

I rarely need additional "Generic" libraries. If that's what you are after you might keep an eye on the Apache stuff--there are a few groups like that that just do generally good work, but most of the stuff you could get in a general library like that you can write yourself just as quickly as you can learn to use their stuff.
Occasionally I need a specific library like an SNMP library or something to provide a specific service--these are actually NEEDed because rewriting them would be prohibitive. These are much more important to choose correctly, but generally there aren't so many to choose from and a co worker will almost certainly have some experience or opinions if you don't.
Researching stuff like this should be a scheduled part of every project--the need to do the research should be identified in the early phases of the project.

Understanding a big company project in Java [closed]

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.