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 going to develop a (relatively) simple game for the Android platform.
It's gonna be 2D-Game (no heavy stuff, maybe simple animations)
I am considering using a framework (like AndEngine)
What are the advantages/disadvantages of using a framework? (rather than developing from scratch)
Thanks!
Well this can be a broad subject, nonetheless I'll toss in my 2 cents.
There are plenty of advantages using a framework and this applies to many other scenarios. Just think of a framework as a bridge to shorten the path and not have to reinvent the wheel.
A framework will pretty much handle the boring plumbing you would have to do otherwise.
Using a framework will, in most cases, make you code faster and some will probably «force» you to code in a cleaner and more organized fashion. Although this has much more to do with the programmer itself...but there are opinionated frameworks out there that will at least lead you the way.
The biggest disadvantage is not using a framework in itself, but picking the right framework. I think you have to make a few questions before deciding to pick Framework A, B or C such as : Is it sufficientlly mature for my needs? Does it have a good community or vendor support? Is it here to stay? What happens if the framework loses pace or support? Will I be in trouble?
There are other disadvantages of course. You may be putting yourself open to the risk of learning the Framework and neglecting the language behind it. For example, you may know jQuery but it's not liquid that you know javascript. See where I'm going?
Also, you can find yourself shackled by the framework limits. You may not be able to have full control of the code you write or at least not be able to express your code better because the framework it self has tight bounds. In other words, you are forced to respect its limits and work the way it is required. Again, pick the right framework for your needs.
I hope this helped.
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 6 years ago.
Improve this question
About 3 month ago, I was charged to do a presentation and a demo explaining what is SOA composition.it wasn't easy to do it because latest eclipse version (neon) doesn't support BPEL projects any more, Eclipse Luna and an extension helped me in this situation.
From that time there's some questions that roam around in my mind :
why there's no new tutoriel about SOA composition ?
Are these architectures are deprecated ? if yes why are they ?
I do think (and this is an opinion) that SOAP/SOA/ESB/BPEL is obsolete and taken over by RESTful Architectures. By RESTful I don't mean things that have a primitive JSON+HTTP API, but real distributed applications, where endpoints are not dumb, but define the part of the workflow that belongs to them.
So, the two conceptual things colliding are: Do I want a central "smart" component (like ESB, and pure BPEL services) and dumb (for example SOAP) endpoints. Or do I rather have no central components and smart "endpoints" (like REST resources).
I think conceptually the latter is the clear winner in many cases (not all arguably). There are practical problems however. Companies always like to centralize. Centralization looks "neat" and "tidy", especially for an Enterprise Architect. Until the central components grow out of proportions that is.
One of my clients introduced an ESB just last year, so it's definitely not over. But I do think (again, this is just my opinion), that we already tried centralized architectures and monoliths. They always end in the "legacy system" bin, that can not be replaced because it does everything. So we know where they lead, we need to try something different. :)
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 7 years ago.
Improve this question
Are having APIs for the sake of QA testing a good or bad idea?
We're developing an application from scratch and we've been creating backdoor APIs to ease the jobs for the QAs. These backdoors do things many things like change the date of the server to emulate progression of time etc. I'm quite mixed on this. The number of these backdoors almost rival the real APIs that'll be used in Production.
Is this the recommended approach? The obvious benefit for this is that it makes the lives of the QA must easier. I can see many disadvantages with this also like maintaining the functionality of these test APIs, ensuring that these backdoor APIs are not exposed in production.
If others have used this approach, what are some good means to ensure that these APIs aren't exposed in production?
For those who are against this approach, are there alternatives to making the work for QA easier?
Thanks
If it's not causing QA to miss issues, it's a good thing to do; if you can make their job easier without costs in the future, do it.
However, normally anytime you test one API but use another API, you're not actually testing the real API that's going into production. If QA has a hack around the normal API, they should also be testing the difference between the hack and the real world.
In this case, it sounds like they have helper methods to modify the state, to enable testing. If there's not a good way to do this otherwise, what they're doing might be pretty darn reasonable... or, at the very least, there may be better ways to spend your time improving things.
But overall; is it regularly (repeatedly) causing them to miss bugs they should have caught?
What build system are you using?
For any software that has any time/scheduling logic, I think it's pretty essential to add a class called SystemClock with a method called 'currentTime().'
In our Android project, we inject the starting time from a Gradle variable, and then we can be sure that there is no way the code can get into production with shifted time (because the variable is defined for the debug build only).
For our iOS release, we were able to use an Extension. That's really a great way to do it because it's only compiled into the test scope. Then it replaces the getCurrentTime method with the shifted one.
The other option you have in the Java world is Aspects. They can be handy for doing mixins in a test build that are not there in production.
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 9 years ago.
Improve this question
When I started to learn a Spring Faramework I focused my attention on specific details but not on clue and global concepts. Actually I can't grasp some of Spring framework goals.
May be this question too wide, but I don't see any sense to divide it into few separate questions. I don't expect that you answer all my question, but at least one of them.
Spring framework goals:
Make J2EE easier to use
Address end-to-end requirements rather than one tier
Eliminate need for middle tier “glue”
Provide the best Inversion of Control solution
Provide a pure Java AOP implementation, focused on solving common problems in J2EE
Fully portable across application servers
“Non-invasive” framework
Facilitate unit testing
Facilitate OO best practice
Provide a good alternative to EJB for many applications
Enhance productivity compared to “traditional” J2EE approaches
Questions:
1). Easier to use? By mean of what? And comparing with whom? It seems for me that comparing with pure J2EE each framework provide ease of use. Please more details and examples.
2). Don't understand this point. What is end-to-end requirements?
3). Don't understand this point.
6). Does it mean that another Spring alternatives isn't portable via app servers? Isn't EJB portable?
9). Isn't it the same as 4th point.
11). Please some examples of that non-productive J2EE approaches.
You can go through below links to know more :
spring forum
spring-3-0-vs-java-ee-6-0
Spring vs Java EE
Why Java EE Lost and Spring Won
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 9 years ago.
Improve this question
I'm still in university at the moment, and I'll likely either try to get security or programming job. My first programming course used a custom library that came with the book. It replaced and added many of the basics of Java like Arrays, completely custom math functions, input (scanner), Hashmaps, Queues and Stacks.
If I did land a programming gig, is it considered unprofessional to use a given custom library such as the one above? Either way, I've pretty much weaned myself off of 75% of the custom classes in favor of standard Java classes/objects, but I wanted to know if slipping in a premade class from a textbook is frowned upon. Thanks guys.
"Custom library" is too broad a category to be useful. Libraries that reimplement functionality that's standard in the JRE, such as the Collections API, are almost certainly useless, and probably did more harm than help in an educational setting. However, there are a large number of tools, particularly Google Guava (enhanced collections like multisets and bimaps), the Apache Commons tools (including string parsing, hashCode building, and the like), slf4j/log4j for logging, and runtime environments such as Spring that are basically standard in the industry.
The general principle is "don't reinvent the wheel". If you have an example class out of a textbook that gets a basic job done that isn't in the standard API or one of the de facto standard third-party libraries, by all means use it, but don't prefer some professor's half-baked and untested implementation to ones that have been in use by thousands of developers for years.
Good programmers write good code, excellent programmers find excellent code.
If your library is any good I suspect it's more a case of everyone grabbing a copy.
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 7 years ago.
Improve this question
I am new to GWT. I have a question. Which way is better to learn/use GWT programming. Either to learn using GWT by writing code for creating user interface OR through GWT Designer? I am also aking this question in the context of good programming practices & industry requirements.
I agree that code is much better. Plus later on when you want to do more fine tuning of your UI, exact position up to the pixel level for example, I have found that the Designer is not very easy for aligning widgets. You will need to get down to the code level anyway to do so.
Another benefit like it was already mentioned is you will get a better understanding of what is going on.
In my opinion it's better to learn to code it from scratch. That way you get a much better understanding of what the underlying code does. Because you'll also have to consider supporting the GUI you develop as well. And if you use a designer, while it's a lot quicker, it'll add it's own code to it, and it may not be pure GWT code.
So in my opinion, code it by hand, sure it'll take longer, but you'll understand it better, and be able to support it. And it'll be another great skill to your bow.
I use a mixed solution. Designer for main blocks and code for details...
I would suggest to start with coding rather than the designer. From a learning point of view, coding gives more information regarding how you can use and extend functionality.
Client side scripting involves good styling, alignment which you will understand once you work via the code and scripts.