Related
This is a bit text Heavy, I apologise. There is a TLDR below.
Intro to myself: I know you all probably heard the same story. Guy wants to make a game etc. Going into it semi blind, and dose not know much of what he's doing. I confess to be somewhat like this.
Next, I'm terrible with terminology, and have a brain like a fish when I comes to long nouns, this is largely due to my (mild) dyslexia, so please forgive me.
I did pre-university computer science at collage some 4 years back. Did some MySQL, some VB.net (windows forms are fun) and JavaScript. I've been following along loosely since then, but haven't done much since then so am quite rusty.
My level of skills can be called enthusiast at best, and muddle-headedly incompetent at worst. Been dabbling in C# since me and a friend use Unity a lot. To by honest college was a little trauma inducing for me and soured my ability to code (minor fear/stage fright, easily distracted), but to get over that I've decided to head out on my own and make something for myself.
Whether I succeed with the project or not, no matter how big or small the project is, isn't important, just so long as I'm creating something I'm satisfied with and I can progress in my skills and learn, that is all the matters. The rest is just a bonus.
With that in mind, I've formulated a project I hope and believe will retain my interest long enough to get some education in.
So without further a do, lets get to why I'm here.
I want to make a space game, a massive space game. Mostly, if not all procedural, but with realistic star counts spanning an entire galaxy. This can range from 1 thousand, to 100 trillion stars (I'd like to go as far as 150t for stress levels then cap at 100), much like it is in real life (Segue 2 - 1k, IC1101 - 100 trillion). Sounds nuts but games like Space Engine have already done this, and that was developed by one person.
Is this practical? I don't really care all that much if this is sort of game is practical or achievable, so long as its realistic-ish on this aspect and a few others. Plus, the thought of "this could work, you just have to be creative and put the effort in" attracts me.
So what's the issue? Why cant I use a normal save file? This issue comes when the game I'm trying to make is somewhat similar to a 4x. Its not exactly, but its close enough to know that there is a lot of information flying around, information that needs to be stored, synced and in some cases processed.
On a small scale, a single home/gaming computer can do this, so having a small single player is fine. However that's not what I want to achieve; The game I would like to create allows multiple people to play over long spans of time, across a galaxy, no matter what size that galaxy is.
This is where I started my research. I need a way to store this information and so I looked up various database engines like PostgreSQL, and others.
I think to myself, for what I'm doing as far as the world map is concerned, for the most part, a standard SQL databased should be fine... right? My confidence started shaking when looking up what game devs are using these day... NoSQL? What on earth is this? Why is google persistent on this? So I looked into it more. I then find out about NewSQL and realise I'm starting to run around in circles. The rabbit hole I did descend.
The flexibility of NoSQL is attractive, but when you see the lack of ACID in terms of fast and reliable queries (if I've read these articles right, I could be wrong), is a massive downside if your trying to look up 1 of a trillion stars or 1 of a quadrillion planets on the map in a fast manner. This is also not taking into account the fact a game is running along side it, sending and creating new data all the time.
Now I could be making a big issue about all this, as my scale of work might me too small to effect even the slow of systems, but how can I really know?
There's also the issue that, I don't know for sure, that somewhere down the line I'll need to create a new datatype for some new feature I create, and go mess things up in my existing test data because the database is old SQL, and you kinda have to deal with a ridged schema. What I need that flexibility to mess around and not worry a table somewhere is going to break, or that I have to bloat the DB with empty or null to non-applicable entries.
Why am I messing around with DB's before the actual game? Well if I cant even create the chess board before I can play chess, there's no point trying to invent chess really... I can make things look pretty later, I need the data first to manipulate.
~~TL:DR:~~
I leu of everything mentioned, I've compiled a small shopping list of a what I'm looking for to store my data:
- Must allow me to integrate into a single application, so my end users can deploy their own privet servers, in a relatively simple manner. What I mean by this, is more a licensing thing, and the easy of integration/use. Simply dragging up some opensource software and stuff it in pre-packaged with the server could lend me in some issues I believe?
- It should not be a cloud databases service, since for this project, I would like to allow "modding" of private servers.
- Relatively scalable, nothing amazing, just something simple yet effective. I like the idea to allow my users the choice to deploy the server software on more than one system with the option to either run a new map or chain to an existing as a slave/cluster thingy, for map chunk loading/dynamic load bearing for busy areas of the map.
- It needs to deal with large-ish amounts of information fast. I'm not expecting a lot of users, but I am expecting large volumes of data per user. Even if that's not the case its better to prepared rather than walk out with your pants down. I don't want to fix problems I can avoid.
- Forgiving enough to deal with a game development process filled with possible changes in data etc.
- Reliable data querying. The map, other than stellar drift and celestial orbits, should be relatively static. And it will become an issue if many users on the same map start looking up planets or stars all at the same time.
############
That's all I can think of for now, and will keep updated if I think of anything else.
So far, for all I could know (which I don't) a standard old style SQL could be the ticket and I'm just making work for myself, but with all the new technology out, like NoSQL and NewSQL, its hard to know what will be the better option for my circumstances. My experience with Databases can be pinned down to the classes done on MySQL and the research I've done recently, so I'm not familiar with the performance and abilities of other software.
So right now, my head is spinning, mystified from over research, and would like to know my options in specific databases engines on the market suitable for my situation.
So I take it to you, great people of stack overflow, please put me out my confusion!
Just agreed to a web project, basically redesign from the ground up. Lots of ui and navigation issues necessitated this redesign.
In evaluating the project was allowed to trudge through the existing sites code. This curled my toes, saw lots of functions with names like getSubSubSubSubSubProductCategory and getSubCategorySubCategory. I just chalked that up to really bad naming/coding.
I didn't consider the underlying db might be as f'd up. I was wrong. Same scary ass table names and on top of that there's 97 friggin tables! I'm not even sure this site sells 97 products.
Would you ever consider working with a db like this? or would you be honest and tell the client he's got a real mess on his hands?
97 tables doesn't necessarily mean a bad design. Normalization means a higher table count than a denormalized design, so it's not necessarily bad.
With that said, I can't judge the design based on what you've posted.
I don't know if the same people who did the bad naming on the web and middle tier created the database. The only way to figure out whether someone smart did the database is to look at it. Check naming, of course, but also look at the degree of normalization, proper keys, good indexes, etc.
Whether or not to take on the gig depends on how much you need the gig and whether you want the challenge. Fixing a big mess might be satisfying: you might become the guy who drained the swamp.
No, be honest, you'll regret it bitterly later if you don't, as you'll never produce a decent solution in a reasonable time.
Also, bear in mind that your client probably knows his system is ghastly, and will respect your giving him a candid, professional opinion.
Finally, assuming he listens, and accepts your analysis, you're in a good position to re-negociate.
This totally depends on your client's expectations.
To me, it doesn't matter how hungry you are - if the client doesn't have reasonable expectations of how much time/work it's going to take, than walk away..
Having said that, it's your job to inform him of his mess. Take a day, do a cursory analysis and show the client the concerns you have. Then, take the time you think it's going to take and double it (maybe triple). Give your client that number and see how they react.
Sounds interesting!
can learn much from such tasks embrace it ;)
UPDATE:
Always trust your instincts.
I definitely should have run for the hills.
So, I work in a fairly small IT section. We have a trouble ticketing system that about half of our end users use. Some of my coworkers don't really do much to encourage our end users to use the system we have in place. The end result? Constant interruptions because end users will get us by IM or come to our offices directly for trivial things. This can obviously make it difficult to do a good job of writing code.
Now, I suppose I could just say "hey, would you mind filling out a trouble ticket next time?", but then I'd come off as the bad guy because others won't do that. I also don't want end users to feel that I'm unapproachable. I just want them to understand that there's a proper way to ask for help.
So what's the best thing for me to do in a situation like this?
Make it appealing to do so.
Mention to the user that issues with trouble tickets are viewed by the entire development team and have been found to get fixed significantly faster. Say that anything without a ticket has the potential to get lost in the shuffle. Provide them outward facing links so they can view the progress and developer/support comments on their ticket. Provide email alerts so they feel like they are part of the process and have instant information about their issue.
Make it as frictionless as possible.
Make the user entry part of the system as easy to use and as intuitive as possible. No one likes filling out tickets and I'm certainly not going to jump through any hoops to do so. No logins, no sign-ins, just type out my issue and contact information and go.
Talk with your team.
Ultimately, no amount of hard work on the above systems is going to matter unless your team and you are on the same page. Call for a team meeting and talk with them about the issue. With your boss present, try and put it in terms he can understand. Mention valuable time lost, issues tracking customer problems which aren't in the system, etc, etc.
Sounds like your manager is letting you down by not forcing users to submit a ticket before getting help. The problem starts there and only continues to your co-workers allowing such behavior. We use redmine at work for application support and have made good progress in telling users "submit a ticket and we will look in to it" but it has to be a consistent voice from all people involved.
Use a little psychology on them. For people that don't send in trouble tickets, remind them that 80% of the people in their department use the ticketing system. Even if it is a lie, it will encourage good behavior because of the bandwagon effect. Remember that the more similar the person is to demographic statistic, the more likely it is to influence their behavior. So "your immediate coworkers" will work better than "people in this entire company."
The people that use the ticketing system should get a gold star, no, seriously.
There was a very brief article in February's Harvard Business Review on using social pressure to influence behavior. It discussed some new research but the article didn't include references.
You don't. Users hate that stuff even I do. Instead your policy should be "don't make me think". You have to collect all you need yourself and automatically handle this in an invisible way to your users. After they opt in at install.
You probably won't make much headway unless you convince your coworkers to use the system first. After you've all agreed on the process you want, then you can talk to your users. If everyone on your team is playing by the same rules, you can probably force your users to use the system by having slow turn-around times for issues not entered into the system, or maybe even forget them altogether.
However, even IF you can convince both your coworkers and your users to enter tickets, you'll probably still find the tickets are incomplete/not informative. We've all seen plenty of tickets like "Feature X is broken, fix it plz" and offer no other information. Depending on the number of tickets you get per day, I would probably just bite the bullet and walk over the user and see what their problem is first hand.
We often log a ticket on the user's behalf in this sort of case.
At my old workplace, I was told that nothing could be done without a trouble ticket. When I asked why, I was told that the support team's productivity was measured by using trouble tickets. This had the effect of forcing me to use trouble tickets (since they were required), and giving me the motivation to do so (I didn't want my coworkers to look bad).
At my new workplace, all technical support is subcontracted out. I literally have to call tech support, and they create a ticket on my behalf.
Also - stop encouraging the behavior. Use your IM filtering options to only appear online to the dev team. Don't check your email - or setup filters that filter the high priority stuff (your boss, your dev team) to your inbox, and everything else to a folder you check once a day or once every other day.
Simucal's advice is good. You -will- have to tell them to "file a ticket" instead, at some point. If you ask them after the fact, they aren't going to care because they got what they needed.
A great way to handle this is to have a dedicated person for support. My team did this, and it helped our productivity immensely and eliminated at least 90% of our interruptions.
Barring that (or lieu of), you can each rotate daily as to who gets to handle user requests. This has the upshot of making a trouble ticket more-or-less required; its needed to keep track of what happened in the request when someone else starts working on it. Over time, this also brings more cohesion to your processes: people create small scripts to do common tasks, work that is done is moved into revision control, etc.
I've been asked to write code/design things in an interview. Sometimes even to provide code samples. Very reasonable and very wise (always surprised when this DOESN'T happen)
I had a job a year or so back where the code was so awful that I would not have taken the job, if I'd seen the mess I had to deal with ahead of time. And I can't tell you how many horrendous databases I've had to work with.
Is it out of the question for me to ask them to provide a code sample and to view their database design? Assuming I'd be happy to sign an NDA, part of me feels it would insane to take a job without examining the codebase or database I'd be working with.
Anyone done this?
Update
This would be something I would ask later in the interview process, if things were proceeding well and I felt an offer was forthcoming.
It's also in the context of working in a small shop or small project as my preference is to avoid places that use phrases like "get a developer off the floor"
You can definitely ask. The answer may be "No," but nobody should consider that to be a bad or inappropriate question.
If they won't show you the code, you should definitely take that into account when you decide whether you want to accept an offer. I would take it as a sign that at least one of the following things is true:
The code is so horrible that they know you'll run away screaming.
The company has an ultra-secretive trust-nobody culture (which I would hate).
The company thinks they have such amazing code that just glancing at it would turn you into a superstar competitor. (In other words, they're self-deluded morons.)
They have glaring security holes that they hope to keep secret.
The people who are interviewing you don't know how to get the code themselves. (In which case you are not talking to the right people.)
I'd be more interested in seeing the company's systems - i.e. test framework, release process, autobuilds.... The presence or absence of those would tell me a lot more than a couple hundred lines of code.
I did ask: "Can I see some code and talk to programmers working here?"
The employer replied: "Sure! Come you can directly talk to our lead programmer of our information system!"
What an honor!
they showed me concept papers
I could talk to the lead programmer
they showed me a small part of a very new project telling: "this is just a prototype, direct3d is so sketchy, that's why this code is so messy"
It turned out that:
the lead programmer left the day I arrived
the software he had the lead, was a big mess
somehow I ended up spending 50% of my time, fighting against the mess
None of the candidates we have interviewed have ever asked that; however, many of them have been co-ops/interns in the company so they are familiar with our code...
Having said that, it is highly unlikely we will show our code to ANY candidate, regardless of an NDA. I would be happy to answer questions about what technologies we use, what system we use for revisions, practices around, etc. Actual code though? No.
Also in a large enough system (as ours is) someone can just show you the "best" code there is...and you would be where you started :) As for a database design...both companies I have worked at have had enormously large databases (university, corporate company)...so that wouldn't work either.
I've asked this in interviews with Xerox PARC, a startup, and Yahoo.
At PARC they sat me at a workstation with the code I'd take over if hired, went over the structure of the codebase super-briefly, and left me alone for around 20 minutes. This was enough to get an idea whether I could stand working with it, though I'd have liked some more time, like an hour total. Afterward I asked about a design decision that seemed dubious, and we chatted about the design and the style in general. This didn't just tell me more about the job, it told them more about me: did I explore their code top-down or bottom-up, what did I pick up on or ask about, etc. Valuable all around.
At the startup, they set up a separate meeting on another day, bringing in the author of the code (who wasn't an employee); we sat down at a laptop and went over things together. It was an unusual request to them and I think I had to sign a new NDA. This was once again worthwhile: my earlier interviews hadn't really cleared up what this fancy AI language was all about or what they'd want me to do with it, and sitting down with some concrete code blew away a lot of fog.
At Yahoo, I didn't see much of anything; I don't recall just what their response was. If I'd seen the code I ended up dealing with I might have had second thoughts (though it worked out all right in the end). (Both of the above codebases that I did get to see seemed generally nicer; the PARC one was open-sourced later on.)
In all these cases I shared some code of my own with them.
If you are going to do this then I think you need to give them a little warning so they can prepare an NDA and get an apppriate environment set up in which you can see it. Also be prepared to dedicate a little time to understanding why the code is in the shape it is.
If you turn up at your first interview and say, right, can I see the code, all but a very few people will say no. And not necessarily because they are evil and don't want to show you, but because it just isn't as simple as saying yes.
In my experience as a recruiter for a large software company it would have taken a considerable amount of time for us to disclose enough detail of the code and internally developed frameworks for any candidate - however bright - to be able to make a meaningful judgement of its pros and cons. We would only contemplate doing that if we were serious about hiring them.
If I were asked that question I woul say yes, come back another time and we'll arrange something. I would get a trustworthy developer off the floor and have them bring a laptop to the next interview and show a little of the code.
The reality is pretty much any software project which is of a reasonable size and has been in existence for more than one release will have some horrible scary rubbish in it.
Similarly to some of the other responses, I've never had a candidate ask to see our code. Even if they did I've be very careful to do so and most likely would not. As Swati mentions, pretty much any non-trivial system will have sections that look good so even seeing the code won't help that much.
Better than looking at actual code is the Joel Test. Basically it is 12 yes or no questions that you can ask an employer. The more yes answers, the better the work environment is expected to be. It's obviously not a hard and fast "rule", but it would seem to indicate those companies that take code (and coders) seriously.
I can't think a reason for not showing some classes or talking about the architecture they're using. From my point of view it's like asking them to show you where are you going to work (room, table, chairs, teammates...).
Anyhow, asking for it will show them you're interested in best practices and also that you're not desperate about finding a job at any price, and don't know how this can hurt.
Go to open source projects. There you don't have to ask for permission to see the code.
It can't hurt to ask and this is a very good idea which I am going to add to my checklist of questions to ask employers.
An interesting idea, but I don't know how many companies would go for it. I know we can't do it where I work now.
I think the biggest problem you're going to have with this is that I have found that a lot of people take offense to people not liking their code. It's like criticising someone's therapist, it's just not a good idea to be an outsider and do it. Seeing the code and then not taking the job could give you the reputation that you're arrogant or not good enough to work on the code and that's why you didn't take the job. It might save you from getting job you don't want, but it could give you a negative reputation down the line. I live in a sizable city, but the IT people still know one another and word spreads. People in our field have egos, and it's easier to trash somoene else's reputation than it is to admit that code you wrote isn't up to par.
Even if they showed you some code, would that be sufficient for you to come to a rough conclusion about the quality of code that you would be spending time with? For example, at my previous place, one of their products was a large e-banking middleware application. The core of the application was in C++ and designed and written in a great way. However, the extensions (which by far covered a large part of the application and its various different versions), which were in C++ too, that were mostly coded by the less-experienced and less-knowledgeable developers were a pile of crappy code (which I had to fix and work with or write from scratch at times) slapped together to just somehow work. If I had asked them to show me a snippet of the code during the interview, and they had shown me some of the core stuff (the extension code actually mostly contained the client-specific business logic so it wouldn't make much sense without the business-domain knowledge, etc), I would've thought that the overall quality of the code is good (which was not completely the case).
More important than to ask for code snippets, I believe, is to ask them for which source code control product they use (run away from companies that answer "Visual SourceSafe") and which methodology they use: "Agile" or "Scrum" sends positive signals, CMMI usually means company loves bureaucratic processes, if they give you a "huh?" then you're warned ;)
I think this is a great idea; however, as an employer, I would be hesitant -- even with an NDA -- to provide an interview candidate samples of real, working code unless I was pretty sure I wanted to hire the person.
The problem is they will show you a little bit of code, but each of their programmers will write code in a different way. You are unluckily to have to work on the part of the code base that is well written.
Asking to see their coding standard and how they enforce it is more likely to be of use.
As much as we would all like to say it is a benefit to programmers to be language agnostic, is it really feasible to support multiple enterprise Web applications of the same type all written in different languages? Think about how complicated a CMS or e-commerce system can be -- now imagine supporting three different CMS platforms all written in different languages. I would hate to be known as a .NET or Java or PHP shop, but I also don't want to be the vendor who says they can support a solution they have never worked with, upsetting a client who wonders why we can't get something done right on time. Can anyone speak from experience on this? Does your company usually just suck it up, and try and to learn a new platform on the fly? Do you bill up-to-speed, or eat those costs?
I think it all depends on who your clients are and what they expect. I think knowing about different technologies is good, but really when you're hired by someone, they expect you to know what you are doing. Personally, I would much rather be known that I do a really good job with a certain type of technology and when hired, I get the job done well.
If you try and go after every contract without regard to what your core competencies are, you aren't going to succeed. You'll anger the people who do hire you and make mistakes, and you'll potentially miss opportunities where you can really shine. Sometimes you have to make compromises to pay the bills, but if you aren't careful, it can bite you in the end.
The large consulting firms I've worked with throw resources at it and hope they don't anger too many people. They mainly do this because they know that the people who work with the consultants and get angry when they don't get the job done aren't the ones making the decisions to keep them hired. To them (not all of them I know, but some definately), don't care if they screw up because they ultimately know they can convince the VPs and SVPs to keep them around.
To be honest, I think you tend to see this kind of thing happen over time, no matter how disciplined the organization is. It's natural for new methodologies to come bundled in the form of new libraries, frameworks, or even languages. Keep in mind that a .NET shop may well have been a ASP/VB shop at one time. They'll probably still maintain older systems for clients, because there's little benefit to rewriting everything from scratch.
I'm not sure anyone has the luxury to keep everything "the same," because language issues are minor compared to library or framework issues -- especially the ones you build yourself.