It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I've been trying to learn GWT for quite a while, I want to build a website that is somewhat advance for my level.
I looked at a lot of documentations/books/blogs/videos, and I just keep getting more confused. Mainly due to facing new frameworks/methods/tools ... etc. in building apps using GWT.
For instance I'm having difficulty answering these questions:
1- Should I use Spring Roo/ SpringSource Tool Suite?
2- What sort of database specification/implementation should I use (JDO, JPA.. I'm a noob when it comes to Java DB issues)?
3- Should I use Google App Engine platform, how easy/useful it is for a start-up project?
4- Should I start coding now, or continue reading and confusing myself (I've started on my POJO data model)?
5- Communicating with the server, RPC or RequestFactory or something else?
Sorry for the many questions, as you can see I don't have much experience in GWT but I'm welling to challenge myself, I just need some guidance.
Thank you.
Taking each question in turn...
To start with no, its extra setting up and its sometimes nicer to be in control of your code and know exactly what is in there.
I would go for JPA with GWT as it is supported by Google App Engine. But bear in mind GAE doesn't provide a relational database and there are quite a lot of restrictions on on what is and isn'ty supported. If you're not using GAE then JPA or JDO are as good as each other.
If you're planning on using Google App Engine then use it from day one and design your app to take advantage of its facilities. If you are going to use this then I would suggest Objectify for your object mapping/"database" implementation as opposed to JPA/JDO as it's a more natural fit.
Yep, start coding now but don't expect the confusion to stop.
I would give the vanilla GWT RPC a go to see what you are dealing with, then try GWT Dispatch or the newer GWT Platform which make the whole RPC mechanism much simpler to deal. RequestFactory is fine too but has some idiosyncrasies that take some getting used to. In the end the choice will largely be personal - they all do the job and do it well.
Other suggestions
use activities and places to control application navigation
event bus for event propagation and to keep your code decoupled
MVP to separate logic/view
dependency injection (Gin client side, Guice server side) to glue it all together
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I've made a chat server using ScktComp and Winsock in a Windows form. How can I make the same thing in an console application?
I found this as a starting point but, the links inside (which the thread's author replied "almost perfect answer") are expired.
What's the equivalent of ServerSocketClientConnect / ClientSocketConnect and the other methods inside in a console app?
Delphi uses the same classes and non-visual components in console applications. You don't need to change what classes you use, but you do need to learn how to add things to units by typing them out manually instead of relying on the Delphi IDE to generate the code for you.
You could create them yourself by using the steps below, or you could use a data-module already constructed while using a VCL Win32 GUI application containing non-visual components, within a console application.
Steps:
Add unit name that contains the class or component you want to use to the Uses clause.
Construct the component as if it were a class:
var
aSomething:TSomething;
begin
aSomething := TSomething.Create(Parameter1,Parameter2);
end;
Remember to free it at the right place.
aSomething.Free;
However I have a hard time understanding why you would want to turn a chat server into a console application, other than as a toy, or an experiment. In real world use, you probably want a Win32 GUI, or else you want a completely non-visual service (an NT-style Service), which you can create, without changing the APPTYPE to console, but which could run without any GUI, nevertheless.
The primary practical reason I can see for writing console applications is to write things which are useful from the command-line, such as build helper utilities, etc. Making a console application is in and of itself extremely easy. Start by creating a new empty console application, add a new empty pascal unit to it, make a main method, then add the unit names you want to the uses clause of the main-unit you are working on. That's all there is to it.
You could keep using the server socket and client sockets you're currently using, although I would like to suggest you forget about the console app, unless you really need it, as all you're doing is making development and operation of your program more difficult for no real purpose. You don't have to change components or classes to use them in a console application, however, I should say that GUI or console alike, that the TTcpClient and TTcpServer components on the "Internet" tab in Delphi are not suitable for real use in any real world application. They are there for backwards compatibility and should be considered "out of date" and "no longer to be used in any serious way".
Look at a real TCP/IP library like Indy, ICS, Synapse, or anything, anything at all, other than those components from the "Internet" page of the component palette, which are not suitable for real world use in any scale other than "toys".
Some VCL classes need a Windows message loop and/or a window handle. So if you change the application type, they can stop working.
Also check if the existing code uses synchronize to run code in the VCL main thread. Using synchronize in a non-VCL application can be dangerous.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I've been doing research on this for the past 2, almost 3 days now. I feel like I've googled everything under the sun on the matter (including these forums) and am almost all tutorialed-out. Before I go into any more details on the question I just want to give a quick overview of the scope and plan for the project to see what will suit it best:
-Large application, non-trivial
-50+ DB tables
-Large user base
-User management/authentication/sessions
-transactions
-security
-MVP (as per GWT recommendation)
-focus on performance and scalability (naturally :), am using GWT after all)
-Prefer to stick with Java serverside
I've also read and watched all of the best practices on architecture for large applications (Google/GWT). In the last talk I could find on best architecture practices involving GWT was back in 2010 by Ray Ryan in which he states that they don't think JavaBeans and property change events work terribly well so it's better to use DTOs for the Model.
The 2 frameworks that came to the forefront in my searching were Seam and Spring.
Sticking with MVP, my domain would for the most part be a data service with a thick client. However, I would still like the serverside to have security and session capabilities since I'd like users to be able to keep state even if they don't use cookies and they end up refreshing for example. I would also like to have an ORM like Hibernate to manage a lot of the transactional aspects. I'd like to still use RequestFactory and have really been considering Spring.
I guess I can narrow my question down to:
Considering the above, what would the recommended application stack be for a large GWT application, specifically for the serverside and integration with GWT?
This is my first project of this scale and the last thing I want to do is head down the wrong path on losing a lot of time and energy. Thanks a lot in advance for your help, I really just want to figure this out so I can get back to coding instead of googling the ends of the earth ;).
-Seth
I've also already looked at Best architecture for applications in GWT which I found might be the closest to this, but it didn't really answer my question and I feel mine is a little more targeted with a more specific use case
I don't have any experience with Seam, however I am working on a relatively large project using GWT on the frontend and Spring on the backend and so far it works really well (RequestFactory, JPA2/Hibernate, PostgreSQL). BTW you can also checkout JBoss Erai
The good thing about using Spring is, that adding new features is quite easy. For example I added support for openid authentication and all I had to do is define an additional dependency in maven and some additional lines in the configuration file and now authentication via google,facebook, twitter account works out of the box.
This layered approach has a lot of advantages.
But if you really stick to the best practices of developing GWT apps (MVP, etc), you will end up with two more or less separate projects. This is a little bit different then when you would develop traditional Spring MVC/Web Flow apps where you have more or a less only one projects (btw: check out Thomas Broyer's gwt maven archetypes which helps you come up with a good project structure).
In addtional to this when you use MVP on the client side your backend will actually only serve as a data service which feeds your GWT client with data. All the flow synchronization will be handled in your GWT app.
So you will probably not use many of the backends functionality (i.e. the MVC part of Spring MVC).
I use RequestFactory for data communication between backend and frontend and for CRUD applications this works really well (it also supported from Android btw).
However if you want to support a more clients you might rather use a Restless approach. Again by using Spring on the backend it is relatively easy to add Restless support to your app and there are a couple of 3rd partys libraries supporting restful services in GWT (RestyGWT, Restlet).
Here are some thoughts on the development process:
Use a dependency management system like maven. It makes it really easy to develop in teams and split up your projects in manageable units/modules (for example a GWT maven app can be split up in a frontend part (GWT), backend (Spring) part and a shared (comong DTO's, etc) part.
Try to do test driven development (TDD or BDD). For example before you create a service function in your Spring backend (i.e. getAllProducts()) write a Unit test for it. This also helps creating a good Service layer because by writing Unit tests you define what the service layer is supposed to do.
"Premature optimization is the root of all evil": Don't put too much time in early optimizations.
Think about buying/using JRebel, especially if you use Spring. A relatively large Spring app can have a relatively large startup time. JRebel helps you to change classes in the backend without a reloading/restarting the application. It saves a lot of time.
Implementing ACL on domain level is not an easy job. There are ACL classes in Spring Security and they work fine for simple use cases however if you have complex use cases (for example filter a list of items based on ACL entries) this can be quite involved if you want to do it efficiently. On the other hand with Spring it is relatively easy to use another library (i.e. Apache Shiro). Futhermore you have to make sure that you display the correct controls on the frontend (i.e. no Edit button if the user doesn't have edit permission, etc). With JSP that is easy because you create the UI (HTML page) on the backend. In GWT you have to do it yourself.
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'm coding in PHP since a long time. And since a few days I've been looking for a job in web development.
Apparently they're looking for people who either knows ZEND or Symfony. I don't know either one (although I did work a bit on CodeIgniter).
And I really wanted to get into node.js these days.
So I'm asking you guys, what should I privilege to get a job? I have a feeling Node.js is going to become something really important and demanded, so I'd better get into it before others do...
What do you think? Are there other things out there I should learn? I really don't want to get into RoR since I do PHP.
I know this is a highly contested topic, but node.js is more of a buzzword than anything and it will not be a skill established companies are looking for. Many people have realized that javascript is far too nuanced to efficiently write large-scale applications, and that doesn't change once it's server-side. If you want job prospects, learn a statically-typed, managed language like Java or C#. These are not trendy, and for that reason a lot of people will tell me I'm wrong.
Agree, Node.js and jQuery are going to be the big winners here; for client side development anyway. Also, ensure you're well versed in CSS (especially CSS3) and are familiar with HTML(5) and how all of these work together to make beautiful web apps.
As far as server side development goes, you're really free to choose whatever, after all, it's rare the client ever sees the actual code that makes a WebService run. If you can make a reliable WebService in PHP, sure. C#? Why not? RoR? Java? Python? The more you know, the more marketable you are, and you get exposed to a lot more code. Personally, just because I'm forced into the big business world, C# is what I use almost exclusively, but only because I use it everyday.
If you get super adventurous, go for some understanding of SQL as well. And network setup etc. But that could be out of the scope of a web developer.
I would agree with the Node.js suggestion but would also learn the jQuery and jQuery mobile libraries for JavaScript.
They offer a huge amount of functions to ease web development along with support for HTML5 functionality. The other nice thing about this is you can write mobile web apps using jQuery mobile and support all platforms (iOS, Android, WP) with one app. It won't be native but it can still be a great looking app with a huge amount of functionality.
EDIT: Definitely agree with everything Breland says and in addition I'd like to emphasize that SQLite on the client-side would be something good to learn. It's a really nice feature where you can create a client-side database if you want to persist data that is a too big for a cookie or you can go with a real database.
Unfortunately AFAIK it's only supported on webkit browsers right now (Safari, Chrome, Android, iOS) but it could be good to learn how to use this and also an ORM like persistencejs which is a jQuery plugin that creates an ORM for SQLite and can work on the client or server-side.
These days, a "Web Developer" means something else than what it used to 3 or 4 years ago. That skill set is further split into disciplines now, mainly front-end and back-end. The path you go with will likely be based on what you've been comfortable doing as a PHP developer.
If you've been building PHP apps the "traditional" way and controlling all aspects of your MVC apps through PHP then learning modern PHP frameworks that make that approach easier would be an easy next step.
If you've been building PHP backends that expose business logic through an API or service layer, you can stick to the backend track and learn to do the same in Ruby on Rails (using something like rails-api) or Node.js if you wish. If you go the node.js route, picking up CoffeeScript will make writing your JavaScript a little more comfortable but it's another syntax you'll have to learn.
If you've done both 1 and 2 above and you like client side development, learn modern Javascript web development. Don't worry too much about which framework to side with yet, just learn the modern way of building large JS apps. A book I recommend for that is JavaScript Web Applications by Alex McCaw (http://shop.oreilly.com/product/0636920018421.do). It did wonders to help me shed my dislike of JavaScript which came from working with the language many moons ago.
My advice would be to learn both sides of the fence and master one or two frameworks on each side. That will make you what's now called a "full stack" developer, which is just a term used to identify those who are effective at client and backend dev thereby making them highly desirable in the marketplace.
Good luck.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Spray framework (spray.cc) seems to be a fun and productive way to build REST services using Scala & Akka. I come from Java + Spring school, where everything is well documented, mature and has good community support.
While Spray is fun to play with but it has its rough edges. I am skeptical about using it in a real application.
Has anyone used Spray in production environment? What about the open source community around Spray? Is it possible to get help easily?
UPDATE: How does Spray compare against BlueEyes (https://github.com/jdegoes/blueeyes)?
We are using Spray in a telco middleware application and I would say Spray is production ready and,
lite weight and seamlessly integrates with Akka
Can easily test the services (No need to fire the container or Akka micro kernel)
Well documented comparing to BlueEyes
Marshaling/unmarshaling JSON is simple & efficient
Can get support from spray user mail group.
I think BlueEyes does not have seamless integration with Akka or good documentation. Not sure it can be deployed inside a web container or akka kernel. Spray's some features are copied from BlueEyes too.
-Jestan
Althouh we are not yet in production, we are using spray for Shopolate, a new startup. So far our tests are showing an excellent throughput, and developing with it is very efficient.
We found no bugs so far.
Answers to questions on the Spray forum are coming quite quickly, but it still remains a starting community. I found the documentation to be quite complete and clear. One big plus is the lightweight / eleganc of the underlying design, which makes the spray source code very easy to grasp and extend.
The only downside that impacted us so far is the relative small sets of features, but it is increasing steadily.
I don't know BlueEyes, so I can't answer to the second part of the question.
Spray is a really nice framework with some exceptionally smart guys behind it. It gives you simple code that scales well in terms of both features and concurrent users. If you want to end up with an application that reads well (good structure, easy to find which url maps to which feature etc), Spray is awesome.
Not all is great though.
The tight coupling with Akka is a two sided sword. For simple applications it adds unnecessary complexity. Think carefully if you want to embrace Akka before going for Spray.
At this moment Spray (1.1M4) has very limited documentation for the directives, so you're on your own mostly, reading advanced Scala code, scratching your head.
Backwards compatibility is not taken seriously so far. Expect to touch all your code when upgrading. This is as much to blame on Akka and Scala itself as on Spray. If you don't like this go with something boring and reliable like Spring MVC.
The Scala language constructs used are so hard to parse correctly that most IDE's get lost and you'll have to wait for the actual compiler to do its job before you know what you're up against. I said before that the code was easy to read, but that is only at a high level. You very easily sort of get what is going on, but to actually get what's going on you'll need a lot of stack space in your head.
I'm using Spray in production and sticking with it (probably), but it's not an easy ride. Expect to be frustrated and delighted in equal measures.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 13 years ago.
Out in the dev lang there are many many, frameworks for all types of languages. For instance, javascript has jQuery, which I use all the time without even thinking about it. Then for php there is Zend and CodeIgnitor, Ruby has rails, Python has django. That's just a few off the top of my head.
I have always been the type of person that was against a framework, especially for PHP. I was always under the impression that using a framework would make people conceive you as lazy developer or to have the inability to code in the raw format. However, for a while now I notice large projects are being made in these frameworks.
I am very curious as to what the opinions are of everyone. Does using a framework make you less of a developer then using raw code, also lets add in a variable and say that you don't already know all the ends and outs of the primary language?
I always lived by the idea that it's better to write everything yourself...
... just to see how it works, then throw it away and use stable frameworks :)
While this may sound like a joke, there's much truth here -- rolling up something yourself will teach you a lot. And what you learn will allow you to better utilize what is already available.
See Not Invented Here.
Using the right framework gives you the ability to get actual, real work done. This means, IMO, you're more of a programmer, not less.
A good framework is indispensable in Javascript, to tide you over all kinds of incompatibilities between browsers that would otherwise drive you crazy. In languages where you have more control over the runtime environment, it's not indispensable, but it can supply you with a lot of useful functionality and stop you from reinventing the wheel -- so using the right framework for the task (which may not necessarily be the most popular one, if what you're doing is a better match for a different framework, perhaps a lighter-weight or somewhat specialized one) doesn't make you a lesser programmer, it makes you an intelligent one;-).
Understanding what's going on at (at least) just below the layer of abstraction you're coding to is an excellent idea (partly due to Joel's "law of leaky abstractions"), but that's no reason not to use a lower level of abstraction than available and suitable, except in a "learning and experimenting way" (i.e. not in production work;-).
Not using one makes you sure hell of a lot less productive however!
The only way to use 'raw code' is to write your programs in 0s and 1s. Otherwise, you are using a 'framework' of some sort. C is a layer on top of assembly which is a layer on top of machine code. That doesn't make a C programmer any less or a programmer - she is just working at a different level. In the same way, using a framework on top of PHP means you are just working at a different level. There are good programmer who build Zend (and other frameworks), and there are good programmers who use those frameworks to build business applications. Being an application level programmer is nothing to be ashamed of - it is hard work to do it right, whether or not you use a framework.
Davidmoreen, does using ASCII make you less of a programmer? I say, go ahead and make your life easier.
alt text http://prontiso.com/images/hardcore_keyboard.jpg
No more than using a language instead of raw binary does.
As the complexity of the tasks we are trying to accomplish increase, our only choice is to build on the foundations that others create. The main goal of any programmer should be to solve a business problem in a cost effective manner. If you don't solve real problems in a cost effective way then you definately less of a programmer.
I beleive it's important to understand the fundamentals of your tools and know how they work. THere'll be times when you need to work on the framework itself or just understand and debug what it's doing.
That said do you really need to remember to call session_start() at the beginning of every page load, or include the config files, or establish a database connection, or any one of the other minuetae that a framework will do for you and leave you to get on with creating the "unique" portions of your application?
I disagree with learining and using a framework without understanding the undelying language and concepts, but choosing to use one gives your code structure and makes you a lot more productive.
Being entirely dependent upon a framework makes you less of a developer. Using one as part of your toolkit when the need is there does not.
There is zealotry on both sides of the argument. You have the ones so starry-eyed about one particular framework that they use it for /everything/ (I usually see them in the form of beginner Railers or PHP programmers). Then you have the ones that are "hardcore" and as such "don't need hand holding", which more or less translates to them using last generation's frameworks instead (beacuse, after all, it's turtles all the way down).
It really comes down to knowing your framework. I would posit that using a framework without knowing its strong and weak points does indeed make you less of a programmer (if you are the one in charge of the decision), and should be counted as a cardinal sin. Study the frameworks, study the problem domain, make the informed choice, not the biased one.
Being able to make these kinds of decisions is what seperates good programmers from the... not-so-good ones.