"Do you think it would be possible to have one technology to replace all others? Would having just one make things better?"
Better or not, it's not possible, for legal reasons as much as anything. Are you going to outlaw the competition? You can't. Forget this one as a non-starter.
the toughest part of web dev is the variety of technologies involved. but having said that if it was easy then i couldn't justify my paycheck. the point it that there are far too many ways that things could go in the future. in the short while (compared to any other technology, like radio) that we have been playing around on the web people have come up with different way of doing things and they don't always pan out. i believe we are still too young for a consolidated stack. if it ever happens, it'll be organic and very effortless. to learn more in this are look at the work being done around jode.js also read google developer's blog about polymer and web components.
Just want to ventilate my thoughts on my plans to build a web UI, turn based strategy game. This has been in my mind for more then a decade now, but it's now first that I got the time to start
I have started with the data model, and thats pretty completed by now. The database used will be MS Sql 2012 Express.
The business logic will be written in C#, simply because thats what I'm familiar with from my profession.
Now to the tricky part, the UI. Tricky at least for me since I haven't been coding web UI for many years
What should I go for here? What technology to choose for a web UI, turn based strategy game? There will be no moving graphics, no sound effects. Just an old school, bord game style, turn based war game with units to move upon a hex based 2d map.
My thoughs so far are leaning towards html 5. Build the map from hexagons placed upon a html 5 canvas object. Then place the game units to be moved on top of the maps hexes, in the same canvas.
Since I'm a c# developer, I'm used to MS Visual Studio. I'm still using VS 2010. In VS 2010, the support for html5 development is very poor but I guess in VS 2015 it has improved a lot, and I will get VS 2015 soon
Any thoughts on the choice for UI technology? Given the fact that C# will be used for logic layers
By the sounds of it you are wanting your game to be played in a browser, over the web. In which case html5 is certainly the way to go, or else you'll be asking users to install plugins or allow an ActiveX component, which is a hurdle best avoided if possible.
Otherwise, you're talking about a desktop application that can communicate with your online server - which is fine, but a) you'll need to convince users to download and install it, and b) you'll have the headache of writing different versions for different platforms.
Even in html5, of course, you must still be aware of how your game will work on different size screens - everything from a dual-monitor 25" setup to a laptop to a tablet to a smartphone....
But there's rarely a "best" way to do anything - or rather, the "best" is what you're best at. And what you will enjoy doing the most. Not much point in doing it at all otherwise.
Thanks for your thoughts! Yes, the plan is to have it as a browser based game, not desktop. And yes, I agree about avoiding plugins such as ActiveX.
The interview is to evaluate what skills you currently have to see if they are a fit for their requirements. If you try and cheat the interview you're not doing yourself or the company any favours. You are forcing them to employ someone and give that person money for a job they are not able to do.
Act more ethically and go for jobs that are within your skill range, and if they are you will get those jobs. With experience you'll get better and will be able to go for better jobs.
As much as anything else, front-end development requires . . . practice by doing. A monkey can do the easy stuff you get in a tutorial. In real work, problems arise. If not, they'd not need you or anyone else: just an application to do the development for them.
There's no substitute for experience. The same is true for any other type of coding you want to do.
In particular, with a user interface, there's painful experience that the user will find a way to screw up anything you do => you learn to anticipate this => they come up with more => etc.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
I am not sure this is the correct forum, so please excuse me if I am posting in the wrong forum.
I am trying to understand the best practices in building SOA applications. Unfortunately some of are not so black or white and need experience to figure out the right approach. Here are some of them:
1) Let's say I am building a REST service for extracting data from various tables. Is it considered best practice to return the whole entity or just the necessary values? The target might be multiple platforms (web, windows and mobile apps).
2) Also, is it RESTful to join entities from multiple tables and return it as a single entity?
3) When joining entity types, should only the necessary values be returned or is it better to form a compound type composed of the basic types?
Example: Consider a REST service that return's an employee's address. The address is composed of the types Apartment, Street, City and Zip Code. Each type has properties (eg: Street has starting and ending lat-lon). In the client only the address <apt number> <street name> <city code> <zip code> is required. How should the return type of a REEST service call be structured?
(It would also help if anyone can provide the recommended URL syntax for this as well. Should there be a specific call like "GetEmployeeAddress" or something like ' <service URL>/Employee/<emp ID>/Address' ?)
I would be very grateful for suggestions for reading materials in this topic.
I think you're misinterpreting the meaning of a REST service. The primary key is that the server itself should be stateless; each transaction must be atomic, having nothing to do with the ones before it, and no bearing on operations that occur after it. It is not just a service endpoint for a database, it is a methodology that pushes state management to the client.
Ultimately REST is more about how data is transferred than it is about what that data is.
1. Bandwidth is bandwidth, but the average entity will not eat very much. It's perfectly fine to send a whole entity down the pipe if you need to. Be mindful that sensitive properties are not sent (tag with JsonIgnore if using JSON.NET eg. Newtonsoft, etc). That's not the case for arrays of entities, page those as appropriate on the server side.
ViewModels are your very best friend. Well, they're mine, anyway.
Completely immaterial. As long as the transaction can be done in an atomic manner you can do what you're most comfortable with. That said, ViewModels are my very best friend, as previously mentioned.
Thanks a lot for your reply, Nathan. It answers my questions very clearly. The IBM article is also very useful. I will have to keep going back to it any time I forget what REST is when I get bogged down by implementation details.