So I want to create an online booking system for reserving tables at restaurants for a personal project, but I have no clue where to start. I don't know what language to use, what to do with the tables in MySQL or anything for that matter.
Any pointers would be hugely appreciated.
This is not the immediate answer you are looking for but I'll give you some pointers base on my experience and the different situations you might be in:
Treat this as a product: Define exactly what you need (if you have, we can help you best if you tell us about it). What is your main goal, what are the features you/the client need, think about the different type of users, build a road map for the whole UX, wireframe each step of the map, prototype, test. Programming-wise, stick to your guns. For example, if you know Rails and mySQL, use that. Do you know something else? Use that then, don't even think about it.
Don't reinvent the wheel, if there is a clear and accessible (read in-budget) option don't rule it out just because. Googled "table reservation software" and randomly picked one (tablein) and it's awesome and the pricing seemed alright to be fair.
If this is purely educational then go nuts. I would suggest following the steps from the first bullet-point and then picking a language you would like to learn or get better at.
All of this is common place for developers. Coming up with an idea just to learn something new, implementing some alien technology to your own code, or creating thing entirely from scratch.
Related
For some time i have been making more or less little games. One level generally, These become incomplete cause they annoy the crap out of me at times, I get an idea than find it hard to implement.Consistantly just run from one problem to the next.
Anyways my latest quest is an isometric game, like simcity or something along them lines
My question is should i been learning these free librarys for instance ISOLIBS to complete this task?
Iv always been hesitent to use extended librarys as i want to create my own base engines, i would assume I would have better control and understanding.As of most the time i have been daizing at a google page trying to think of ways to structure my apps.
This is more of a trivial question, but im after a trivial answer that may direct me to a more proffesional approach, for instance other library's or personal , comercial opinions.
Please keep in mind i think i am confident in programming but i havent had no formal experience at all so this is my classroom.
Thanks
Looking at a project as a whole will definitely give you a feeling of a daunting task ahead.
Well the scenario is similar if you are going to start with any project.
So, nothing really special to AS3 here. But here are my 2 cents:
Since you are learning, don't even expect the commercial side of your
project before hand.
Pick up a project & stick to it. Make sure never start anything else
in parallel.
Don't decide to use any library upfront.
Break your project into smallest of parts & pick only one part at a time.
Start it. Simply start the first sub problem... one after the other.
Decide to use a library for a problem only if you have atleast
theoretically dealt with the problem & don't wish to spend time
writing it.
Maybe or maybe not you get a game out of this one, but the next time you surely will.
I've decided to get some experience working on some project this summer.
Due to local demand on market I would prefer to learn Java (Standard and Enterprise Editions).
But I can't even to conjecture what kind of project to do. Recently I had some ideas about C. With C I could to contribute to huge Linux projects. I don't mean that my work will be surely commited. I could get the code and practice with it. But C it's not right thing to get good job in my area. In case of JavaSE there is a chance to develop some desktop applications. But thinking about JavaEE I get stuck. I'll be very thankful for answers.
CodingBat.com will give you good core Java practice.
Project Euler is still the best for all around practice. You can use whatever language you'd like to solve the problems there.
For actual projects, I almost always start on something easy like a Twitter client. It gets you exposure to all the basics along with UI and network communication. You can work up from there. Just don't start with something so overwhelming that you can't figure it out and want to give up. That's not going to get you anywhere.
The best advice is: work on a project that you have personal interest in. Something based on your hobbies, maybe.
If that doesn't work, make a blogging / CMS engine. Or an online photo album. Or an eStore. The world doesn't really need another of any of these things, but it will give you some good practical experience with JavaEE.
Another benefit of "re-inventing the wheel" (for learning) is that you have probably already used systems like these described above, and you have a good idea of how it can work, and maybe you have your own ideas of how it could work better. That can make requirements much simpler, and also will give you a sort of benchmark so you can see how close you can come to building a tool like the "real" ones out there. And if yours is really great, well, maybe release it and see what happens. ;)
There are many Java-based projects on SourceForge. Tinker with one you find interesting.
I've implemented either a betting pool or a Baccarat game in almost every language I've
learned.
This type of software covers:
Dates and times, with calculations
Currency types and things that can be converted to and from currency.
A discrete set of rules that is easy to test
States, transition between states and multiple entities responsible for state transition
Multiple users with different views of the same model End conditions
Multiple player blackjack and poker would work also.
One caveat is that in my day job I work on financial systems and there is a huge overlap
between things to consider when writing a multiplayer game of chance and a trading system.
build an address book. the concept is simple, so you're not stuck on "what" to write. You can focus on learning your chosen language. You get experience in working with a database, java ( insert any language here), and UI design.
when you decide to learn another language you can create the same thing. Since the database has been created already, you can focus on the language itself.
the concept of inputting data, storing data, and retrieving data is central to a lot of applications.
Have a look around http://openhatch.org/ for a project that sounds interesting.
We have been trying now for a while to assist the management (of a customer) with the implementation of a a new system that is custom developed by ourselves, to their requirements. Their old system is text based (DOS) and their employees have been using it for years. The new system is Windows GUI and have many advanced features which will make their lives easier and their organisation more efficient. The problem is that the staff do not want to adapt to the new GUI environment and they are now resorting to be unfriendly and as unhelpful as possible, often placing serious obstacles in our way. The management is adamant that implementation must proceed. The system runs trouble free. We have been consistently friendly and helpful with all parties.
Any advise would be greatly appreciated! Have you encountered something like this before and did you manage to turn it round?
Note:This question is intended to help Programmers etc. with implementation difficulties by sharing experiences and factual solutions that worked. It is not intended to be subjective and indeed Programming techniques may help to solve the problem.
Use the tool
Somebody needs to really understand how the existing tool works. Not just well enough to walk through it; but well enough to do it for real. Why not take 2 weeks and go and do their job with them? That will both improve your understanding of the tool, and may foster a better working relationship with them. And while you're there, perhaps buy the drinks once or twice - it sounds corny, but anything that lowers the hostility, and lets you communicate.
User experience
Getting a good developer (or better: designer) who understanding user-experience is probably key. You can't just completely change their tooling and expect their productivity to remain the same.
Keyboard use:
Think of tools like Visual Studio, AutoCAD, etc - in most cases you don't need the mouse, and "die hard" types wouldn't notice if you took their mouse away. Try to respect this; provide shortcuts / chords (ideally the same as the existing system).
Terminology:
Keep it the same. Don't invent new terms for things.
Talk to them?
This may or may not be possible, but getting a few key users "on board" early can be pivotal; especially if you genuinely empower them to help with the user experience.
Find the faults
In the existing system. Take away their existing pain points and they may forgive you a lot.
Unfortunately it sounds like a case of needing to close the barn doors after the horses have bolted. You really need to get grass roots buy-in on the need for an improved system before beginning the project and maintain that relationship during the development.
By having champions of the system at the "coal face" level in the business would a) make sure you meet not only the management requirements but also the users goals which is all important in a successful system and b) the users get a system to which they have been a development party not just had a system thrust on them.
Getting people to moan about the short comings of an existing system is easy. Describing possible new systems before its create in way which allows the users to comment enables them to feel some control and gives you vital feedback. Be absolutely sure to identifier those killer gripes about the old system and make sure those are addressed in the new system.
Of course this all a bit late for you. The way forward is to create a review forum with the most vocal opponents and put them in a room with you and management. Get them to defend their reasons for not wanting the new system. If you can't show how your new system is better then perhaps it isn't. If you can see how the new system might be slightly improved (the movement may only need to be small) then do that, it may go a long way to get back the feeling of involvement you missed out on before.
I would sit together with the staff or a couple of the more loud mouthed opposers, go through what they find lacking with the system and suggest some of these changes to be incorporated in a future release(s). That way they will pay more attention to your the system and also feel more a part of the process instead of just being handed something like some peon. In addition it would also help avoid any misunderstandings about the system.
Get one / more of the user to be your champion by involving them in the development process. Make sure to choose the right ones. Hopefully one that you can reason with. When launching, do a launch event. Make it a big deal. Not necessarily applied to an application, but I've seen it worked in my previous work environments. If this is too late (you went ahead without any involvement from the actual users before), well... there is always things called staff turnover, lol. Out with the old and in with the new. Make the new users your buddy :).
You have to show some kind of benefit for making the change. A demo / mockup can be useful for this. Choose a manager to demo it to and wait. Let it become his idea. Then it might move forward. Being to pushy can cause a negative knee-jerk reaction which might block further consideration of the idea.
It is sad that software often gets replaced by a management decision without any user involvement and then people wonder why the system is rejected.
I've witnessed this first hand. A guy I once worked was told to develop a new version of an application "in secret". At the end of 6 months development it was shown to the users. It didn't meet their requirements and they were angry they hadn't been involved. Needless to say the software didn't make it into production and the developer left shortly after (I felt sorry for him as he had wasted 6 months effort and actually did a real good job considering the circumstances).
The chances are that the software is inferior to the previous application- perhaps data entry is actually slower (you will be biased as you wrote it- everyone likes to think their software is better).
Re-engage with the users, do some analysis and work out what is bad about the old system. If the new system can address the grips the users have with the old system you might be able to turn this around.
Edit- who was involved in engaged with your developers? Presumably the managers at the client, who probably never use the system? This is another big mistake people tend to make- managers driving requirements.
If the old system is perfect, then it never needed to be replaced in the first place!
I'm working on a product which is meant to be simple to use and simple to set up, the competition largely requiring a long set up period and in some cases going as far as a bespoke solution for each customer. One part of our application is now expanding based on customer requests and it is looking like we'll need to make it very flexible so each customer can have a lot of control over how it behaves for them. The problem being that I don't want to make the system too configurable, as I believe this then makes it more complex to learn and to work with. I'm also concerned it opens the door to someone messing things up for themselves, kind of like handing them a gun, although I'm not actually pointing it at their foot for them.
Has anyone else faced a similar dilemma of putting power in users hands? How did you solve it? and what was the result?
I don't normally like to subscribe to the idea that all users are stupid, but there is a rule which can still be applied:
If you give them the opportunity, they WILL break it
Now it is up to you whether or not to give them the ability to do potentially dumb things. Or better yet, develop it so that when they do do the stupid voodoo that they do, it can be reverted or recovered from error state gracefully.
I highly recommend you read Joel's Controlling Your Environment Makes You Happy, which can be described as a treatise on user interface design but is really about usability with a healthy dab of psychology thrown in.
The section I'm referring to is Choices:
Every time you provide an option,
you're asking the user to make a
decision.
This is something I strongly agree with. Many developers, product managers and so on take the easy route and instead of figuring out what users actually need, they just give them a choice. You see this in enterprise bloatware like Clearcase or PVCS where there are so many options--90% of which you'd never change--indicating the designers have tried to make it all things to all men rather than doing one or two things exceptionally well.
Instead it just does lots of things badly.
Keep it simple, follow conventions, don't overwhelm the user with pointless and unnecessary choices and make the software behave like a normal user would expect. That alone would set you apart from an awful lot of other products.
Personally I like the TurboTax model (http://turbotax.intuit.com/). When creating a tax return, I get a simple, tell-me-like-I'm-five wizard that takes me step-by-step through the process, but I can step outside the process at any time and use more advanced features, returning to the process later.
Make it easy and simple and uncluttered for your user to do what they're going to do 80% of the time, but give them the power to deliberately step outside of the norm.
Interesting timing for your question. In the U.S. this is Income Tax week. Filling out the ol' 1040 and associated subforms should give us some sympathy for what users endure.
Lessons I take away are:
Only ask questions that relate to the user domain; avoid questions relating to the software system; and if you can derive the answer or suggest a most likely answer, do so.
Put related questions together (as long as they are normally entered by the same person using data most likely available at the same place and time, which is the definition of related for these purposes).
Make it support incremental input. It should be easy to enter the data they have, and defer completing it when the rest is available.
Show status validity and completeness. Make it clear and obvious how far they are to having validatable data.
Make it interruptable. Make sure it's possible to interrupt the process, leave the application, come back, and resume where they left off.
Yup, it's harder to program. Embrace it.
There are at least two ways to build a good software product:
Focus on a narrow set of functionality, and implement that functionality very well.
Design your system to be customizable (ideally, through scripting.) If you do the base system right, it will be easy to provide the basic, no options, just-do-what-I-want functionality on top of the customization layer.
Unfortunately, there are many more ways to create a bad software product.
Your questions implies that you can either provide a flexible solution OR make it foolproof.
I wouldn't put it like that. To me this is rather a matter of user expectations and the question in the first place would be:
How can I meet all important user expectations (even if they conflict with each other) without corrupting the application?
For instance a web application which has a menu, breadcrumb navigation, a site map and a search offers together with the inline links five different ways to find what you're looking for and how to go there.
That way most users can find fast and easily the functionality they are expecting and therefore the need for an extensive documentation might actually decrease.
So the answer might be to offer several different carefully chosen ways to solve one specific task, while each of them can be streamlined independent to avoid user mistakes.
The answer with this lies in who your end-users are. I used to write software that got used by professional sports coaches. While these guys were definitely good at what they did, they were hardly proficient at computer use, so our configurability was kept to a minimum (at least as far as what could be done in the GUI).
On the other hand, if you're dealing with power users, adding options is usually not a bad thing as long as they aren't intrusive.
It's all about who's going to be getting them.
Read Jeff Atwood's Training Your Users. It's a great article with some very useful links.
I like the approach of Firefox towards this. The basic options are accessible in the option menu, all the rest is under about:config. Thus you have an easy interface and an incredible flexibility if you need it.
I've had great success, and been happiest as an user, when using sensible defaults. In other words, make the most common use case easy (or even better, free), but give users the ability to step outside of that use case when the situation calls for it.
I'm not really asking about how programmers learn how to program. More about specific technologies. If I wanted to learn Hibernate, how do I know what I should know prior to Hibernate? Should I learn JPA before, during or after Hibernate? Is there a better solution to Hibernate? (And I'm not really looking for information on Hibernate specifically)
Maybe stackoverflow is the place to find these answers, but it seems like with the shear vastness of frameworks, apis, libraries, programming languages, platforms, and whatever other techie word you want to use, it takes an extremely long time to come up to speed on what technology to use, when and what you need to know prior to using it.
Sometimes the best way to learn is to just dig in to a framework. Sure, you could use someones wrapper API around something, but if there is something wrong w/ hibernate, then you wouldn't know what's happening.
And to answer "how do i know what i should know prior to hibernate", you don't, that's why you are learning. When learning about c++, started out with simple data types, but i didn't know about pointers yet, didn't need to, but i learned about them when i got there. Just gotta jump in and start playing around.
I use Wikipedia to compare various technologies to copmlete a task, although it can be incomplete with regards to commercial closed-source frameworks (probably because fewer people have access to them).
For specific technologies such as Hibernate, Java, JPA, LDAP (OpenLDAP in particular), Log4J, anything Apache: they all have wikis and/or forums associated with the product that are usually more helpful than a Google search for learning. Many even come with tutorials and you should try them.
Find a book on the subject and read it. Then email the author with additional questions. Most of these authors are more than happy to help especially if you've bought and read the materials they worked so hard to produce.
If that's still not enough for you, go to a conference covering the subject, if you can make it. Again you can meet many of the people responsible for maintaining and/or creating these technologies and I've found they are always willing to answer questions.
go to sites like Coding Horror, Slashdot, Techcrunch etc and find out what people are talking about. Usually if something is popular it's probably something you might want to talk a look at.
There are these things called "books" that are filled with all kinds of knowledge.
A lot of the time the documentation and/or tutorial for any technology or project will mention what prior knowledge is assumed or useful.
So for example hibernate: http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#tutorial-intro
"This tutorial is intended for new users of Hibernate but requires Java and SQL knowledge"
For me, the things that have helped my career and taught me what questions to ask are:
Podcasts -- .NET Rocks, etc., which introduce and discuss new technologies and put them in context
Join your local users group, and stick around after the presentation to talk shop with the folks there; you can learn a lot just by hearing what other people are doing and what they are working on learning next
Just look around online and start trying to use whatever tool/technology your trying to learn. As you try to learn one thing, you'll realize your lacking knowledge in other needed areas. at which point you can repeat the process of looking around for this new item you need to learn.
for example, maybe you want to learn Rails, so you start following rails tutorials, but you realize you suck at Ruby. so then you start to focus a bit more on the details of Ruby, then come back to Rails with a little more knowledge and continue on till the next roadblock. this isn't really totally correct, but you get the idea.
you won't always find a full guide of how to use everything. just give it a shot and work it out on your own if you have the time
There is an infinite number of things one could learn. Maybe a better approach would be to think of a project that interests you, or join an open source one, and then learn what you need to know to accomplish what is needed in that project. When you're done, pick a new project that might include new things not learned in the last project.
As far as free sources are concerned, as a .NET programmer I like www.asp.net, and there are many others, such as the ASP.NET quickstart tutorials at http://quickstarts.asp.net/QuickStartv20/default.aspx, C-SharpCorner is good, too, if you don't mind C#.
If you don't object to paying a little money, Lynda.com is a decent place. They have OK tutorials on all kinds of things, not just programming, and I got a decent grounding in Javascript using one of their tutorials. They are adding new things all the time, so if they don't have something on Hibernate now, they may later on. I think their basic rate is $25 per month, but you can just pay for one month and then soak up as many courses as you can find time for.
Asking a more specific question will get your a more specific answer here. When I want to read up on something I usually head to Wikipedia and then Google.
The truth is none of us have the time to read everything we'd like to. So I let someone else do it for me!
The way I solve this is by speed-reading the web - aka. subscribing and reading to other peoples blogs.
Everytime I come across something I'm not familiar with I google it.