We Keep Coding

how to choose a 3rd technology for apps in phonegap [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I need some help on how to choose a technology for developing mobile apps. I have decided to use phonegap (cordova library) and Jquery mobile with HTML and complete my device APIs and UI parts.
Now I am in a dilemma, on which technology to use to connect to a database -
1. PHP
2. .NET
3. JAVA
I heard/read PHP is light-weight and is easy to work with but .NET is more robust and secured. Now, I am unsure of what exactly security here means? Does it mean PHP is not a secured way to handle database operations?
Can anyone please guide me on how to decide on a technology and take my development to a higher level?
I can give you more inputs as required. :)
Many thanks.

If you never ever touched any of these technologies you should use the easiest one.
Your priority should be like this, I will rank then from according to their usability/simplicity:
1. PHP
Good:
By far simpliest of them all. In a matter of days you can learn more then enough to create your basic server. No matter do you want to handle only REST calls or do full a page creation on a server side.
It has largest overall support and you will easily find hosting, if you already don't have it. It works on all current desktop OS's like Windows, Linux and MacOS.
Bad:
Not that much. If I have to think of any I would say that it is a smaller brother of Java and .NET.
2. .NET
Good
My favorite, more secure (but not that much secure) then PHP. It requires much more time to handle and use right. Like with Java I prefer its syntax over PHP. Still more readable syntax then Java, specially if you delve into something more complex.
Bad:
But, as it is a Microsoft technology it will run only on a Windows platform. Skipp it if this is a turn off for you.
3. Java
Good:
Almost best of both worlds. Better and more powerful syntax then PHP and unlike .NET you can run it on any available platform. Like .NET it requires more time to master correctly then PHP.
Bad:
Java is usually used in large corporate projects and you will not find that much help over some basic stuff and usage. Even if you master it correctly you will still need to delve into Java EE if you want to create anything decent and robust, basically it is a largest time sink if you only need to create one server application. Other problem is memory consumption, that is why you will see much less available Java hosting platforms the it is case with .NET and PHP.
Conclusion
If you don't have that much time and you are not sure you are ever going to use it again then stick to PHP. If you are planing on using this technology for a longer period then stick to .NET. And finally if you are going to use it in a longer period but Windows platform is a turn off then stick to Java.

Web App. Vs. Desktop App (Java Swing App) [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to develop an application where server pushes a lot of data to client. (20 kb every 20 milliseconds) 500kbps. All of the data are double/float values.
I am trying to answer the question, if there is something inherent to desktop apps (Java Swing app) which will make it a better option for this use case as compared to a web app where data will be pushed over http.
Is there something about Java swing app and how data transfer takes place there from server to client, that makes them faster as compared to web apps (tomcat as app server .. JS at client side).
And how answer varies, if I say that web server and application are on the same local network.

My vote is desktop, but I'm bias (when the only tool you have is a hammer...)
My first thought is threads and custom networking. You get the added benefit of push and pull protocols as you need (yeah you can get this in a web environment to, but Java was designed for this, AJAX has been bent this need)
I'd also push a diverse and customisable UI toolkit, but one might argue that you can achieve this using HTML, but I've, personally, found the Swing toolkit faster to get running & easier to maintain, IMHO.
The downside would have to the need to install the app on each client machine and deal with updating
That's my general opinion anyway, hope it helps
The other question is, what does the app need to do?

It is highly unlikely that the UI will be displaying 1000 meters all at once. The users will most likely be looking at small number of meters at a time. The UI only needs to be updated for the meters that are displayed on the screen. This should cut down on the load considerably. Assuming that networking and cache database components will be about the same for both web as well as desktop app, the real differentiator then becomes how fast the charts/graphs can be rendered, and how often or how many people will be inclined to use it.
MadProgrammer's suggestion of prototyping make sense. The test data gained from the prototypes would answer the performance question.
Web based will be more useful/valuable because it can be used from any desktop, tablet or smartphone. I am assuming that it is desirable to get the data in front of as many users as possible, anytime and anywhere. Also, I don't think human eye can detect 20ms updates. You could probably make that longer and users would not even notice it. Movies are about 25 frames a second, i.e. 40ms/frame.
How many concurrent user are you anticipating? I don't think that should affect the solution as both can be made scalable.

Java-based i18n/L10n [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've seen internationalization implemented in a classic ASP shopping cart as a most-massive monolithic dictionary of (int,String) key-value pairs, where the calling code passed the dictionary an integer representing which string was to be returned (binary-ORed with the desired language id) and the value for each unique int was the "internationalized" string.
This seems like a very, very, very horrible way to implement i18n.
I'm in the "pre-design" (if there is such a thing) phase for a Java-based Swing application that I would want to be internationalized. Not that I speak anything other than English (ha!) but it would be nice to expand into other languages in the future without having to refactor 20,000 strings.
So, this begs the question: what are the best practices surrounding Java-based i18n (and L10n for that matter)? What sort of classes & structures are used? Obviously, if this winds up as one big com.myproject.i18n package with an "Internationalizer" class as the common gateway for the rest of my code, I would want this to be a singleton class, yes?
Just a request for some food-for-thought here, any nudges in the right direction are greatly appreciated :-)

The idea is to work around properties files. They are easy to work with and you can extend this system easily.
You can find a nice answer here.
Netbeans have also a great sample tutorial.
After you get your languages right, you will need software to switch locales, localize dates and amounts etc. Kai Toedter' tools are very reliable. You can add these beans to your IDE and drag and drop them to your JPanels.

You can create your property file and insert them into iL10Nz.
In order to evoid context issues, it is good to have a scrrenshot for each strings that you are progressively creating. This will pay off with the languages you will translate into
Check http://www.myl10n.net

You can take a look at Gettext Commons. It's i18n in gettext-way for Java. It has Maven plugin for generating, updating and compiling PO files. Personally after some time of use found it's easier to go with standard ResourceBundles.

i using netbeans for developing GUI application based on Swing Application Framework [SAF]
and you can get powerful tools for internationalizing Project on Netbeans IDE.
look at this article : Internationalizing a GUI Form

BlazeDS vs GraniteDS - 2 Years Later [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am currently using BlazeDS and covet the features of LCDS, but am never going to ask my customers to pay the $$$. Therefore I am considering starting to build these capabilities myself, using third party tools (dpHibernate?) or switching to GraniteDS.
Since, we are coming up on the two year anniversary of the last time this question was asked, I thought I'd ask it again.
Since that time, Spring-Flex has added Hibernate serialization support to BlazeDS to avoid lazy init exceptions. There is also a new BlazeDS configuration option to serialize read-only properties.
On the other hand, the Tide capability of GraniteDS seems to be maturing.
Plus the servlet 3.0 spec has been out for a while and maybe the additional support for NIO makes a difference for those who need push-type messaging.
So what's the latest?

As of today (February 29, 2012), the GraniteDS community is still very active, the product evolves with new features on a regular basis and you can get developer and production support if you run into technical issues (see here) or just want a kind of insurance for critical deployements.
GraniteDS' messaging is based on asynchronous servlets, it is mature (introduced late 2007), proven in demanding production environments and much more scalable than the BlazeDS messaging stack (based on classical servlets).

I've never used GraniteDS in production, but in my opinion it will always have more goodies than BlazeDS..unless some company will decide to make money from BlazeDS, like adding features, offering paid support & professional services. I think that Farata Systems is doing that but probably they are doing custom development for various clients..and not adding features into the mainline.
So probably from a productivity point of view GraniteDS can be a good choice - before choosing it I will double check if the community is quite active, if you receive answers to your technical question on their forums and most important if it's easy to understand the GraniteDS source code in case you run into technical difficulties.
Related to messaging I assume that if you wish a professional solution you will not choose niether BlazeDS not GraniteDS - there are dedicated solutions on the market. If not both should be ok (BlazeDS has a little bit more options from what I know).
By professional solutions I mean LCDS, Lightstreamer, Kaazing (and probably more). Some important features from LCDS which are not included BlazeDS: reliable messaging, message throttling, the ability to deploy the solution in architectures where DMZ is a must (http://www.lightstreamer.com/architecture.htm), the ability to connect also to non Flex clients (HTML).

Actually we (Farata Systems) continue improving our open source offering that works nicely BlazeDS. The latest version (4.2) of our tool called Clear Data Builder can generate CRUD applications in minutes based on Hibernate or POJOs. We hooked up Spring framework too - all BlazeDS client's requests are processed by Spring's DispatcherServlet.
Here's the Wiki Page http://cleartoolkit.com/dokuwiki/doku.php. There are screencasts and a workshop at the bottom of the main Wiki page that takes you step-by-step through the BlazeDS with Hibernate process and you'll also see how easy it is to connect the Spring Security module. We support data synchronization, hierarchical data collections, transactional updates, pagination, and more.
Apparently, we need to make more noise to make this nice (and free) product more popular :)

Best tool to do load testing of wicket framework? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Can you recommend a simple/best tool for an web application developed using Wicket framework?
The challenge is interface id is changed every time so record and playback may not work. This link explains some work around but it is not simple to implement.

Besides JMeter you can try Selenium to test web applications. If you use Selenium you show also check Selenium Inspector which is build on top of it and provides convenient assertion methods.
Online service BrowserMob offers cloud based load testing based on selenium.

Because the web framework like wicket is on the server side but the load testing tool operates on the client side almost any load testing tools should do the job.
What may be worth a look, depending on your needs:
Apache AB - The 1st generation load testing tool. It just requests defined urls. However, it's very fast you can easily create a high load from a regular computer. It's a console application
JMeter - One of the first script load testing tools. You can program a test via clicks from some basic actions/validations using a swing interface. Or you can use the proxy recorder to save some amount of work.
But, to be honest, the tool doesn't satisfy me anymore these days.
The Grinder - A nice tool - you program the test case via python (in fact jython). This makes complex testing scenarios easily possible. This should defnitly work with wicket, but this tool is also getting old.
Deja Click - A firefox plugin which allows recording and replaying web actions. Intentionally not written for web tests and load tests, but it may be worth a look
Selenium - The 3rd generation of web load testing tools with a big community behind it. You record and edit your test cases via a firefox plugin. Because of the browser integration, more complex tests cases can be recorded in a shorter period of time.
You should really have a look at this, but keep in mind that Selenium is a acceptance testing tool, and not designed for load testing, but you can do it, if your hardware allows ist. However, you might be in troubles recording the tests if your application does not run in firefox.
LoadRunner - A commercial and well-known load testing tool by HP. Haven't tried this yet.
WebLOAD - Another commercial alternative.

None of the above-mentioned is good at first sight, speaking from experience.
Depending on the complexity of your app, you may need different tools than the ones enlisted and there's no straightforward answer.
If you want an easily recorded and correlated scripts - TruClient by LoadRunner - expensive solution.
Next comes Selenium , but it is generally hard to do any load testing with it, unless you have enormous hardware resources, or your app doesn't require the 100% of the client (load generating machine's CPU or other resource) unless you want to invalidate your test.
Wicket is very dynamic and although it may seem like easy tool for developers, it's kind of hard to be properly tested.

JMeter is the tool you are looking for if you don't want to sacrifice your firstborn to get a license.
JMeter provides a proxy you can use to record everything you do.
The record HTTP-Actions can then be tinkered with and played back.
In most cases you will be able to avoid building Wicket-URLs on your own.
In all other cases it's quite obvious what you have to do (increment a counter ...)
Additionally you get everything you need to generate useful statistics.