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 2 years ago.
Improve this question
I would like to build a simple cross-browser multiplayer game (like chess or a card game) which will communicate to a server using sockets.
I have some intermediate knowledge of Ruby language, but I'm not so convinced that it is a good solution for a multi-client server, so a thought that Node.js or Socket.io might be a better one. I know that Java or C++ could be great for the job, but I am not too comfortable with none of them, so that is the reason that I'm levitating towards Server-side JavaScript.
My question is, what do you think is the best solution for a project like this one? What might be the best server-side technology on which I will build an entire game and communication logic? Maybe some combination of them? Any comment regarding speed, server load, hosting solutions and development speed for each of the technologies will be greatly appreciated.
If you're comfy with JavaScript, you've got nothing to lose by giving node.js a go: the learning curve will be gentle. It's a pretty cool server tech.
Only disadvantage with node js is of course it won't scale like java. At all. This is often fine for web apps because you can throw a caching layer in front (reverse proxy), which greatly mitigates this. I imagine this won't be reasonable for your application, since the game state will change too frequently.
Node js can "scale" though, by spinning up more instances. If one server can easily accomodate more than one "game world", then this is straightforward. If you need to split a gameworld across multiple servers, then servers must cooperate. Beware this scenario though, it's not as simple as it first may seem: it's called the "multi master" problem and is one of the hungry internet monsters.
Related
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 4 years ago.
Improve this question
I can see the time employed in maintaining lots of microservices with functionality not independent from each other. Clients, queues, routers...a lot of stuff that maybe is not totally needed for attending the needs of conceptually simple projects. What is the downside of merging several microservices in a single monolith? If the project itself is the only consumer of most of its microservices, I think that partitioning a large app is just wasting time for the sake of following a supposedly good practise in an scenario in which does not fit.
Microservices provide for set of guide lines that help you build applications which can scale easily, which are more available and which allows your team to bring around changes really fast.
Having said that, it does not really closes the gate on monoliths or any other guidelines that you want to follow while building stuff.
There will be cases when building a monolith will indeed be a better option.
Say you are starting with some thing new, and you domain knowledge is not good. It will become really hard to break your application into services. In depth understanding of the domain is required to break services into effective smaller independent chunks.
Second could be you are doing a POC or MVP (with plans to test waters) then perhaps you can build everything as one.
With microservices, like I said you get scale, availability, maintainability and speed to make changes. There will be projects where these are not really a concern, and if they are not you can keep away from it.
Lastly, with microservices, you need to have a solid dev ops. you need to have CI/CD pipelines, you need to have monitoring, centralised logging etc, because trust me you will need it to debug stuff. It is indeed big investment and you should think what you are getting into and why you are getting into.
You should not be using it just because every one else is.
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 8 years ago.
Improve this question
I am planing to write an social network application and thinking about to use dart on backend. But I am asking me, if dart would be the right choice for backend application. I was searching in internet about this topic, but could not find something useful, that convince me to use dart for backend.
I am thinking to use golang, but I have to learn this language from zero. In dart I have some experience and really like dart language.
You know, I try make the right choice to use right tools, so I need some suggestions? Dart or golang?
I know, that java provide me hug ecosystem, but i don't like to learn java at all, just don't like java.
I would choose neo4j database, i am pretty sure, this suits for social network.
I don't like Java very much and developed a server in Go. I enjoyed working with Go a lot. Then I started with the client and because I also don't like JavaScript (in fact I hate it) I went with Dart which I like a lot. I already did a lot of server side work in Dart. A big advantage is that I can share code between client and sever, which is actually a lot in my current project.
I like Go better for server side development but I will stick with Dart for projects where I already use Dart for the client. It's just too difficult and time-consuming to stay up-to-date on two different languages (and ecosystem and libraries) for such new and fast evolving languages.
I think each language is a very good fit for this Job. Java has an awful lot of existing libs, tutorials, ... but most of the important things are covered in Go and Dart as well.
Basically I would say, stick with the language you know best. Learning a new language will impede your productivity for several months at least.
If you design your application in terms of loosely coupled modules then you can write(prototype) modules in Dart and if one day you will need to re-implement some of them in GO (for example you need better performance) it will be doable. Look at REST
Also it will make your application scalable and you will be able to expose API for separate modules (for example, if you need some of them as a phone app back-end or for the 3-d party developers)
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
There are lots of texts on how to plan software projects (with user stories, etc), but they usually assume you have a large budget, liberal timeframes and/or a real dev team available. While they sound fantastic, they never seem to account for solo devs working on a short deadline.
There is also a lot of talk about test-based methodologies where you write a test case for every method before you implement it, but I feel that these are difficult to impossible to apply if your software is GUI-focused (e.g. (server-side) web programming or Flash/ActionScript).
Although I try to make heavy use of refactoring to improve my code whenever I have finished a section of it, last minute hacks and additions tend to make this incredibly frustrating and I often feel that there should be a way I can utilise at least some of the planning theory that's apparently meant to help large dev teams and developers of software libraries first and foremost.
What is The Right Way to go about writing small-ish applications as a solo dev and how do you prevent last minute changes from making your code worse?
There is no "Right Way" unfortunately, however, there are a lot of better ways. I think there is no real distinction between small and large projects - the same kind of things need to happen, it's just the depth of those things that changes.
In your situation - working to a short deadline, preventing last minute problems - the same old tried and true methods are going to work:
Use source control effectively, develop last minute changes in a separate branch so you can drop them easily if required.
Test, test, test. If your tests cover the intent of what you were trying to achieve properly then last-minute changes can be measured.
I suspect you need to look seriously at some different types of testing and tools - there are plenty around that will help you manage these issues.
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
Which is a good Project Managment Method to Develop a Website?
XP? The Waterfall Model?
Anything but waterfall....
But keep in mind that saying you are agile and being really agile are two different things.
For agile to really work over an extended period one has to also be doing several technical things well.
http://ayende.com/Blog/archive/2010/02/20/nice-process-but-what-about-the-engineering-bits.aspx
http://davybrion.com/blog/2010/02/youll-never-get-sustainable-progress-for-free/
Agile/XP would be best.
Waterfall would be the worst choice in my opinion.
It depends on who the customer is. If you are your own customer, then definately Agile.
If your aren't your own customer then you will have to negotiate with your customer on your development method. If your customer wants a fixed bid project and a hard deadline, then you will be best served by the waterfall method.
If your customer is willing to be an active participant in the development process and doesn't have a hard deadline and fixed budget then you could do Agile/XP.
It always depends on the type of the website you are developing, how many developers you got, what is the timeline, expectation for delivery time. But definitely Agile or prototype-iterative method will work fine for website development. To complete the development in different phases, and enhancing in the chucks, as an when identifying the strong and weak areas.
As well you can check the factors like target audience, maximum used sectors of the site and prioritize the development of those pieces first.
Always consider to go with standard framework, that will make life easier in long run with the future developments.
I find that waterfall fits some web site projects fairly well. Get the requirements, wireframe a design, do the graphic design, convert the graphic designs to HTML/CSS/JS, then fill out the content of the site. Client signs off at each stage. If the site is large the last stage ("fill out content") is probably more work than all the preceding ones and you'll want to use iterative methodologies for it, not waterfall.
Waterfall tends to not fit web applications very well. Those are software, treat them as such.
Use waterfall! But:
Set duration of the project to 1 month.
Then repeat this project until customer is happy!
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 8 years ago.
Improve this question
To make my question clear:
I'm experimenting with XMPP, lately - I have set up my own XMPP server and trying to figure out what uses could it have in our development process. Except the obvious things (we use it for IM-ing and have set up a group chat room for our team), we employ it as a notification platform for our issue tracking system and our continuous integration system.
I have already thought about some other possible uses such as monitoring the state of our servers (via the presence layer), application exception notification (via PubSub), etc.
My general idea is to build some kind of unified support system for our development process that will communicate through a regular IM client (PubSub support would be great, though) and will make our processes much more transparent and more responsive.
Have you ever thought about something like this? Or do you use something completely different for this purpose? Am I just reinventing the wheel?
Web site notifications (most likely through changes published to Atom feeds) that get pushed out to subscribing IM clients via pure PubSub or PEP (PubSub subset) are going to be a big application, outside of vanilla enterprise instant messaging.
I wrote a bot that knows how to talk to our ticketing system (our Trac site). Users can ask to see the tickets for the current sprint, tickets assigned to them, they can "grep" through tickets, get the current Milestone information and update ticket fields (workleft, status, owner or attach comments). That's been pretty popular with several developers -- and getting people to keep their tickets updated is a Good Thing.
IMified (imified.com) is a pretty nice way to build out the kind of applications you are talking about.