I want to create a texttwist using Java with a GUI, but I don't know where to start. Can somebody give the steps to create my text twist project?
Well, this is a pretty broad question. The fact is there are dozens of ways to go about it. Do you have any Java experience?
Assuming you have no Java experience at all, I would start by finding a few tutorials online, whatever looks good to you (the official tutorials, though, are an excellent place to start). Then go on codingbat and get really comfortable with the basics of Java (also, a good understanding of the Java Collections Framework is essential for doing many things). You can do that before actually choosing an IDE (Integrated Development Environment, like this or this) to use for future coding.
Once you feel okay about actually writing code, start reading about Object Oriented Programming. Learning to make your code sufficiently modular will actually allow you to work more quickly, as you'll have fewer bugs, will be able to make large changes more easily, and will be able to reuse code.
Next you'll need to be able to create a GUI. Having just started in java, you'll most likely want to use Swing, which can very quickly give you something nice to look at. I think many Java IDEs now have Swing design tools that allow you to drag-n-drop components into your GUI.
Once you have a solid understanding of everything that you're going to have to use to build your TextTwist you should be able to plan it out. Draw some diagrams of your program, both how the classes fit together and how you want it to look (I use MS Paint and Dia). Make sure you know what you need before you start programming. Document everything you want the program and each class in it to do. This way if anything isn't going to work you'll know before you've written half your program and have to go back to fix it.
At this point, it should be a piece of cake! Get a dictionary library, pick a seven letter word, check every combination of its letters against the dictionary and store those. Provide some way for the user to make guesses (through your Swing GUI!), and a way to record them. Stick a timer in there, et voila! TextTwist.
There will be a lot of hard work in there, in and in between every step. But if you read as much as you can and keep asking questions (the more specific the better) it won't be so hard. The biggest obstacle when I started was getting discouraged when I bit off more than I could chew. Take small steps and the distance will fly by.
I find that a good place to start is just looking at existing code.
With that said, I have an Eclipse project that implements TextTwist (multiplayer) in Java that I put up on GitHub, if you're at all interested:
https://github.com/fangsterr/Multiplayer-Text-Twist
I've implemented simple GUIs that hopefully you can learn from. Hope this helps!
Related
I've worked my way through the tutorial series of jme and feel like I've understood the basics. Now I would like to create a first very simple game. Nothing fancy just a simple test scenario: The player should be able to move an object. Then I would like to expand it. However I don't know how to start. It's hard to explain but I just don't know where to put my code. The manual says that there are "controls" (implemented as interfaces) that let you hook your code up to frequent update calls or other events (that's what I understood) but I can't grasp how to use them.
More detailed description. You could skip this:
To get the point clear - I'm coming from the engine Unity3d. The usage was quite pleasant, the community helpful and the documentation great. But you have to spend about 1000$ to get the full version and be allowed to use pro features (shadows, custom shaders, some advanced tools,...). After a while the temptation of open-source was simply to big. In unity3d you basically have an advanced 3d editor and a scene graph. You can place objects in the scene and access and modify them over the scene graph. You can use predefined objects such as lights or particle systems and change them to suit your needs but most things you use are custom made and puzzled together by different components: a mesh, a collider, a few scripts. And this is where your code comes to work. In unity3d your program is split into small scripts and these are added to the objects of each scene. The scripts have access to the underlying engine, the properties of their object and can use a special framework for math, networking,... Each script can also define functions to be called in certain events: update(), onCollisionEnter(Collider other), onTriggerEnter(Collision other), ...
This was extremely easy to use. Admittedly huge architectures can be difficult to implement but this setback was complemented by very high productivity.
Frankly: I need advice how to structure a simple game with JME.
What architecture do you recommend ?
How are controls used ?
I would appreciate a link to a tutorial (I already read the flagrush series) or any other resource.
Thank you for your help
I'm not sure how well you read the tutorials but they quite literally explain the things you asked for.
Anyway, you code everything so you don't add an object and put code in it you instance an object trough code.
Input is handled by the InputManager, as long as you still use SimpleApplication as foundation you don't have to think about it and use it the way you learned in this tutorial
Obviously, it's easier to do with some developers, but I'm sure many of us are on teams that prefer the status quo.
You know the type. You see some benefit in a piece of new technology and they prefer the tried and true methods.
Try, for example, DBA/C# programmer the advantages of using LinQ ( not necessarily LinQ to SQL, just LinQ in general ).
For example, When a project requirement is to be cross-platform... instead of thinking about how one can run Windows on a Mac through a VM Machine, introducing the idea of using relatively new Silverlight or creating it in Java ( as an option to look into ).
I know most people don't like to be out of their comfort level, so it takes a bit of convincing, and not ALL new technology makes business sense... but how have you convinced your team to look at a new technology?
What technologies have you successfully introduced to your workplace?
What technologies do you think are hardest to introduce? ( I'm thinking paradigm-shifting ones, like MVC from WebForms... or new languages )
What strategies do you employ to make these new technologies appealing?
Know the technology well before pitching it. You're going to get questions like "but how can we make it do X?", and you want to be able to give at least a general answer.
Try not to be a religious zealot. Acknowledging that the new technology is not perfect, that it's just another tool in the toolbox, goes a long way towards credibility.
Give a well-prepared live demo to show what it can do. For example, a friend of mine built a simple blog in Ruby on Rails in half an hour, in front of a live audience. I want to stress the word "well-prepared"; if things keep breaking along the way, or you don't fully understand what you're doing, or you are unable to answer basic questions, you'll hurt your cause rather than help it.
When it comes to coding practices my favorite is to quite simply use examples. I will take a few hours and edit our code base to use the new technique in place of the previous pattern. Then send a shelveset or changelist around to the rest of the developer list displaying the difference. Or just have a meeting to talk about the difference.
Showing examples in real production code really helps other developers see the advantages.
I've successfully introduced LINQ to my company and it has helped quite a bit.
What worked for me? Show and tell. Our previous technology was database programming with C, which is quite the mess. Our lead developer did about 3000 lines of code to fill a dataset, and I did it in a 10th of that with LINQ/C#.
Once I broke down what I did and he saw how powerful it was, he was convinced it was time to upgrade.
The advice from people who convinced the management to consider using F# goes something like this:
Implement the most important bits of the next key project of the company in F# in your free time and then show others what benefits it has, how quickly you were able to implement it and how easy it is to adapt the solution to changing requirements.
I think this is quite effective way - when people actually see the productivity (of any new technology), it is much easier to convince them that it is worht learning it.
It's best to lead by example. Complete a successful project using the new tool and wait for developers to ask how you did it.
I managed to convince the team Im part of to switch from CVS to Mercurial. Can you believe we were still using CVS? Neither could I when I started.
I became almost somewhat of a preacher, a royal pain in the butt. Everytime CVS screw up or caused some sort of discomfort (being brutally slow, for example) I held a little speech of how much better it could be.
Soon enough they accepted the possibility that there were alternatives (none of them actually knew there were alternatives to CVS!) and began to say things like "if there indeed are alternatives, anything must be better than this".
Thats when I made my move and simply ran some scripts converting the CVS repository into a Mercurial one and uploaded it to the company server. Once they saw it in action, they were sold.
Not that I planned anything during this little migration black ops, but in retrospect I would give the following advice to anyone attempting something similar:
Let people know there are (better) alternatives, it is entirely possible to work outside your comfort zone.
Lead by example, if you want something done, do it yourself. Show the alternative in action. No one is going to make the jump unless you jump first, especially not if they are already hesitating.
Show them how it solves a common problem. Pick out some problem that appears regularly for them and show them the solution. That will usually at least get them thinking about it.
Stand the two technologies next to one another, its safe to assume that advancements have been made and that what you are bringing to the table is better suited to the job at hand.
Put the raw results in front of them and let them decide for them selves!
I work for a data beauro, and until recently the company was hooked on MS Access, which was cumbersom and unfit for the job, after some serious convincing and showing the power of SQL in comparison to Access, its now the weapon of choice.
And it took standing the two techs side by side and allowing the guys up top to see for themselves, the time saved did make business sense!
You'll need to show why it's a BETTER technology (or at least better at something) than the current tool/method in use, and probably significantly so. Otherwise, why go through the effort of learning something new?
Otherwise, convince the boss and then get a mandate ... (though I don't really recommend that if you can't get at least half the team on board).
I've done a little research, and am interested in developing for Android. I've never programmed before, and have no idea how to go from zero experience to developing for a mobile device. My interest is in eventually making some sort of 2d game.
Is there a lesson plan for starting from the ground up? I would think one would need to learn the Java language to start. Looking at the Sun website, it's a bit daunting. Is there a book, specifically, that would wrap up this knowledge in a bit of a directed lesson plan?
I'm not sure if opengl-es is what would be required for 2d games. I've done a little research on this, and it's even far more daunting than Java itself. I can't even begin to figure out where to start with even just opengl, sans -es. My best guess would be that I need further knowledge in Java to continue with this, but even still, is it possible to learn concurrently with Java?
The typical answer from experienced programmers is that one should start with Java before moving on to Android-specific code, but I disagree. I think the most important thing for a new programmer is to be able to see the fruits of their work quickly and in a context that feels useful to them. In other words, you need to have some sort of personal project that you're trying to complete. This gives you more motivation than working on some random program in a textbook, and you learn by overcoming the specific obstacles en-route.
Now I must add that I am not an experienced programmer, and I have never tried to teach anyone to program. In that sense, CommonsWare's comment should hold more weight as he has written multiple books on the issue and thus has experience as an instructor. However, I speak as someone who has taught himself to program in Android-Java essentially from scratch. I had dabbled in a few languages like VB (for Excel macros) and C, but I never wrote anything more than about a hundred lines of code long and didn't know anything about object oriented programming.
Of course, doing things this way will be messy. You'll often read tutorials and be confused by why they are doing things the way they are, or for example, what they mean by a "private static" integer or class inheritance. You'll also program with poor style, solving problems with a clumsy or inefficient manner. However, I think these problems are outweighed by the benefits of personal motivation. It's much easier to study something if you know why it matters to you.
The trick however is to make sure you choose easy projects to start with. You must realise that programming anything useful will appear complicated and difficult. Trying to start with a 2d game will not work; there is just too much to learn first. The best place to start is the tutorials on the Android Developer's website. Work with those and see if you can modify them a bit to do different things.
After that, see if you can find some simple things that irritate you with your phone (note: I'm assuming you actually have an Android phone), or things that would make life easier. In my case, I wrote a few very basic programs to do things like change the volume of my ringtone at one press, to go from silent to mid-volume and vice-versa.
Once you've done that, you can tackle bigger projects. Of course, eventually you're going to have to knuckle down and read the 'proper' Java tutorials as you can't bumble along half-blind forever. But to reiterate the point, I think it's much easier to learn if you know why it matters.
Above all, be patient and persevere! It's fun once you're past the initial bewilderment!
For learning Java I would recommend a book like Big Java or Core Java. Only once you are comfortable with the language would I recommend moving on to mobile development. I have never done any Android development myself, but recently worked on a J2ME project and I found that books weren't much help. Instead it was best to just start working on tutorials you can find online then gradually work your way into developing small simple apps for yourself. Build your app bit by bit learning as you go.
Probably the most confusing part of it all is learning how the langauge all ports to the new platform and getting your head around building and deployment. But if you start off with small samples you will come across these hurdles early on while it is still easy enough to work out what you need to know, and then you can come back here with specific questions and no doubt there will be a number of people who can help.
I am a fairly novice Java programmer and I am currently working on a project to extend a piece of software that has been developed over a few years.
So it has pretty big code base and the previous developers knew it well, so extending it is not going to be easy without a thorough understanding of the structure and function.
1) I had begun by trying to tackle small parts of the system and document them with mindmap. (particularly I am trying to document the interactions with external systems)
2) I have the book "code complete", which I am working through.
3) I have pointed some tools like "tattletale" at the code to get some diagrams of dependency relationships.
What other strategies should I employ, should I focus on one particular aspect?
10 Start small.
20 Break things.
30 Then fix what you broke.
40 Goto 20
Maybe you could try to model the problem the program is meant to solve. If you have a clear understanding of the problem and limitations imposed on the solution, then it should be easier to understand the program itself. I am just guessing here, as I do not know what sort of program it is.
It is important for you to find a good coach on the project. Go for a nice guy, who knows the system and who likes to answer your questions.
Also have the architect explain you the system. If it is a good one he can point you to the important parts and point you away from the parts you do not need to know (yet).
Then try picking up small issues. Even stupid error messages and go from there. In a few weeks you should be able to grasp the basics of the system.
Good luck!
My question is broader than merely expanding language specific skills. I'm wondering what sort of advice anyone might offer to someone with a desire for knowledge, but a lack of direction. Feel free to skip down to the question.
Background: I've taken a single computer science course in java at my University, but i'm planning on majoring in Computer Science and Electrical Computer Engineering (ECE). My java class was quite rudimentary. We were provided with a framework and merely edited/created a few methods and classes to perform a simple task. We made a version of Breakout, and created an AI for a simple connect-four game. Although I'm somewhat familiar with big O notation, I haven't actually studied it in class (My next CS class covers this). In my introductory ECE course we also programmed BOE-Bots in PBASIC to compete in an obstacle course of sorts. As an engineering student, I was also introduced to matlab, although I've only used it for linear algebra homework. In summary, I don't have much programming background, but I've loved pretty much everything I've done so far, and I'm looking for ways to build a more valuable skill set.
Steps Taken: After paying more attention to the programming section of reddit, I found a link to Project Euler. This summer I've been hacking away at those problems (finished my 42nd solution yesterday), but I'm looking for some more direction. I've been reading blog entries and SO heavily. I'd like to learn something about php, and perhaps create a dynamic webpage, but fundamentally I want to do anything in my power do to improve myself and prepare for the working world.
Question: What would direction would you recommend for me? Should I learn a new language? Keep attacking Project Euler? Read some books on programming? Start a coding project(I wouldn't even know where to begin)? Wait until school? Learn about more fundamental programming principles?
I guess with all the paths available, I'm just a little overwhelmed, and I don't want to fall into a path that might be detrimental to my career opportunities. I'm also really bad at making decisions. Your advice would be greatly appreciated!
The word quickly worries me... I suggest you read Teach Yourself Programming in Ten Years - Why is everyone in such a rush?
~~ Peter Norvig
Forgive yourself if you're not setting the world on fire three weeks after sitting down at the keyboard... maybe you're destined to be a late bloomer?
;-)
Most everyone is suggesting doing more programming. Whilst that's obviously important, I think it's important to understand the environments that your programs work in.
I would investigate how operating system work (how they allocate resources for you, how they schedule programs and threads), how networks work (routing, TCP/UDP behaviours and limitations etc.), and some database theory.
I see a lot of junior programmers with great language knowledge, but beyond the sandbox of their program they don't have a clue how the computer/network enables their stuff to run.
Knowing something of the above will make you a better programmer in terms of how you write your programs, and how you understand how they'll work (and indeed, how to debug them or analyse their failures)
There is only one thing that can improve your skills as a programmer: Program.
Reading books about programming is akin to reading books about cycling. It's not going to turn you into a cyclist.
Program something that you'll use and have a vested interest in. Then just put your head down and do it - reading any supporting information as you go.
Programming skills are just a small part of what makes a successful programmer, IMHO. Being able to read specifications, ask questions and interact with other people to extract the information you need to program are very important too. Pay attention to your 'soft' skills, they will help you a lot in being a successful programmer in a commercial setting.
I'd reccomend you take a multi-pronged approach. Reading books can only take you so far, since they don't provide you with practical experience in developing an application from scratch. Programming is much more now about writing code; you have to be able to design applications, read documentation, and know how to solve the needs of a customer who doesn't know how to tell you what to write.
If you're still in college, try to find an internship with a development firm. You'll get access to people and resources who already have this experience. If you for some reason can't do an internship, find and make a friend who is a developer. The impact of having someone who knows what they're doing to bounce ideas off of is immeasurable.
In addition to surrounding yourself with people with knowledge, you should also take on writing an application all your own. Pick something that interests you, but at the same time try not to make it too complicated, you don't want to frustrate yourself by writing a boring application, or choosing something that has too steep of a learning curve. Remember that the application is at it's core, a tool to assist you in learning, so it's OK if it turns out to be less complex then you imagined, or if the code you're practicing doesn't apply within the scope of what you're trying to write.
You definitely need to write code in order to become a better programmer. If you don't have a particular idea for a program to write, pick an open-source program (ideally one that you use), contact them and find out what they need done; contribute something. Fix a bug, implement a feature... start small and work your way up. This will help you learn about working on a team, writing maintainable code, preventing problems, and working on useful tasks. Much of what people write while learning to program is just exercise code, and not actually useful or representative of anything realistic. That is why a real, useful program is the best thing to do.
I saw an interesting link for a site called CodeKata that might help you. The important thing to get your skills going quickly is to actually code for practical problems that you will be likely to encounter in any real job.
Besides picking an interesting project and implementing it from scratch, reading others' code can also be valuable in improving your skills. Scott Hanselman has a good series on reading code: Weekly Source Code
Since you already know the fundamentals of programming, and obviously have the desire to learn I would start a pet project.
Nothing has forced me to learn great deals about a technology, language or idea more than having a fairly challenging pet project to throw my self into.
I would recommend, like rein mentioned, picking a project you really have a true interest in. Other wise it will get boring pretty fast and you'll have no idea why you are working on it. I think it would be wise to make the project fairly non-trivial. I always found the less trivial a project I was working on, the more I learned and took away from it.
Also If you live near a college/university research labs on campus are pretty much always looking for summer interns to work on code in one shape or form. Some will even pay you. I did this for 4-5 years through high school and some university and it was a great learning experience.
Obviously participating in an open source project is a great way to gain experience at working with other developers. Check out stuff on github, sourceforge, bitbucket.
I'd only caution you to ask for help and bother the core developers of a project you are very interested in and you are going to stick with. Generally open source developers dedicated to there project are few and far between. Their time is really valuable to the community and to waste it on someone who is just going to fly by night and never be seen again is kind of a shame.
It sounds like you are writing programs happily, and are a decent java programmer. So writing more might not be your most productive way of learning new things.
As a result, I'd say learn a new language - knowing more than 1 always exposes you to new concepts. As a java programmer I'd suggest C/C++ as they've immensely popular but they fill areas that the 'managed high level' languages don't go, the low-level high-performance, to-the-metal applications. If you learn C# (for example) you'll find you're just doing a different dialect of java (roughly) and you won't learn too much.
If you don't like the idea of C/C++, get into a scripting language instead - bash, VBScript/WMI, or perl or python. they'll be sufficiently different to teach you some good stuff.
Or do both!
You already know how to program; in order to prepare yourself for a real life job, the most important thing is probably not how to program better, but to learn the things you'll have to do that aren't programming.
In your workplace, you most likely won't be asked to write line "fire and forget" programs, but work in a team on large applications. In order to do that effectively, you need to learn:
How to communicate effectively with analysts, customers, managers and your fellow programmers
How to plan and coordinate work: using source control systems and bug tracking systems, working with written specifications, following a development process - "software engineering"
Perhaps most importantly: get used to working with other people's code - third party libraries, frameworks, and of course colleagues' code.
This, too, can most effectively be learned through hands-on experience in a real project. For me, the big eye-opener was working in a group of about 10 students in an experimental project organized by university with some industry support. Perhaps you can find or organize something similar at your university? If it has a chair dealing with software engineering, they should be happy to do something like that if they aren't already. Failing that, joining an open source project is good too.
Write programs to automate things that you do manually on a daily basis.
Like, todo lists, keeping accounts, checking RSS feeds.. the list could be endless. If you do some business on the side, write some simple code to assist you in that.
The essence is: to improve your programming, do programing! :D
Contributing to open source projects has a surprisingly high impact on your ability to develop software, as opposed to the ability of writing code:
you get to work on code written by others, which is sometimes brilliant and sometimes abysmal;
collaborate within a geographically distributed team;
get introduced to team politics ( yay! );
understand what it means to have actual users.
to quote just a few. Some good places to look:
Codehaus
Sourceforge
Google code
Find out about best practices (for example training videos on windowsclient.net). Get any problem and solve it using database as input and database as output. Start over several times. That's as close as you can get to the real world scenario. Read books recommended by Joel.
Here's my multi-prong suggestion:
1) Big picture work - Look at various Software Development methodologies and see how when you program you follow one of these approaches. You did some Java work, was that web, windows application, console application, or something else? Learning a little about the other types may also prove useful
2) Medium picture work - Have you looked at Refactoring and Design Patterns? These can be very useful but may require a bit more coding experience to see how they can be useful.
3) Small picture work - Study various algorithms and understand various trade offs one can make in choosing various implementations of a data structure, e.g. linked lists vs. arrays. There is a big white book about Algorithms that some use when studying them.
My multi-advise:
Keep training, and write code. Participate in small open source project.
Read standard book (here is the Jeff's list)
Learn from your mistakes, or better from the mistakes of others by reading site like www.badprogramming.com
From 99 ways to become a better developer:
Program! and try to diversify your work as much as possible
Find a mentor
Be a mentor
Learn about the different aspect of software development other than code (business of software etc.)