Is there a Java library that provides functionality for developing social network applications such as add friend, find nearest neighbors, send message etc. I know this is too much to ask for but just wanted to know if such library really exists or not.
This is very broad functionality. Here are some related projects:
OpenSocial Java client - it implements the OpenSocial protocol
Spring-social allows integration with popular social networks
Apache Shindig an open-social based platform.
If you want to add support for existing social network applications than I think all of the Bozho's solution would be ok for socializing your applications. For distance based calculations (geocoding) you will have to use separate mechanism and librabry google and yahoo both have an excellent api for that though these differ in terms of their usage restrictions so its good to you research before deciding one, Yahoo also supplies a promising feature YQL which is also useful in some cases.... Which one of them is better depends on your requirements... see following questions finding latitude and longitude, another similar question and finding distance between two zipCodes
If you want to create your own social networking site as then I think you will have to start by ur own... However It would be a nice idea to integrate that site with existing popular social networks using OAuth or open ID....
#Bozho's answer is valid, all those libraries integrate with a set of Social services.
This question really depends on the extent of integration you want. I've worked on a couple of large scale Social aggregators and I've found that such a silver bullet just doesn't exist. I've found the best results in my experience by using small lightweight libraries that do one thing well.
For example, say I wanted to integrate with Twitter, Facebook, and Google Talk. I might use Scribe for my authentication code, Jackson for parsing JSON API responses to my business objects and Smack for doing my XMPP work.
There are certainly pros and cons for both methods; the major benefits I've found of avoiding massive libraries are:
Flexibility. For example your business objects only contain the information you care about.
Testability. You can compose your components in such a way that tests are easy to write around them.
Robust. You are not constrained by a 3rd parties implementation of typically volatile 3rd party APIs.
Less code. Using a collection of small, proven libraries will result in less of a footprint: less code to manage = less that can go wrong.
Related
A few months ago I created a shop manager software for one of our customers.
One of the requirements was Adobe ColdFusion. Nevertheless, I came up with a really nice product, simple and fast, a few nice ideas and some positive feedbacks.
Now I think I am ready for letting "bigger" customers see my project.
I prefer not to write that next version in ColdFusion, I'm looking for something much more scalable and reliable.
The cloud computing, actually, is making me really curious! In particular, Google AppEngine seems to have all I need:
I know Java
I could start from scratch, without paying anything
It's Google, what's more reliable than it?
I made a few helloworld-s, looking for the best technology to use.
GWT is really nice, but my dev team loves html+css "page centric" apps, so I think it would be a too high jump. Instead of it I was considering:
Spring MVC 3.x
Objectify 4 (as a persistence manager, instead of JDO/JPA)
My questions are:
Based on your experiences, do you think that GAE is suitable for developing and hosting a "shop manager" software, which will manage tables (CRUD), make reports, and so on? My projects is really simple.
Do the two technology I mentioned are good and enough for such a project? What will I need in addition?
I've made an pretty standard shop, using: Appengine + Spring + Groovy + Objectify (and backbonejs + google closure templates for client side)
And from my experience I can say:
It's possible :)
Such system requires a lot of transactions - it's possible, but not so trivial using appengine. There is a lot of transactions, and a lot of work
Reports is better to prepare on background (taskqueue/cron/prospectivesearch), and it's hard to prepare 'on-demand' or custom reports (actually it's must be done on background anyways)
I'm happy with my current implementation, but I see that using an standard RDBMS fits much better for this type of projects.
PS And also, you can take a look at CloudFoundry, I didn't tried it yes, but seems that it's good thing too and it have PostreSQL as service
I actually want to ask that what is the way to create an API for sites such as Facebook.. Twitter etc. I am an IT Graduate and do know programming but still wonder that how do people start to create their own set of API's for such websites. And Everyday people have a new API to access the site. Can someone throw light on the standard process that is being followed so as to achieve this ?
I think there is no unique canonical way for the design of a public web API. You could find best practices through.
This will also depend of the complexity of what you want to expose.
Basically you'll want it to operate over standard HTTP and be accessible both by backend systems and by browser client. So you'll choose either XML or JSON as the dataformat as it is supported by everybody.
A common pratice would be to adhere to the REST architecture, but this is only one choice over many. Today REST is a buzz word. So many tend to use it even if not really suited to their needs.
Like any public API, you should take great care of backward compatibility and futureproof design. The whole refactoring thing can be thrown away as you can't break client code when developping new features. A classical way to deal with this is to publish API per version and let the client stick with the version it support.
Check Spring Social. It is a framework to write api to connect to social networking websites. Also for doing that you need to have knowledge of OAuth protocol which is one of the protocols used to allow access to private information with other websites.
I have a startup considering building a Java backend and a Rails frontend. The Java backend will take care of creating a caching layer for the database and offer other additional services. The Rails frontend will mostly be for creating the webapp and monitoring tools.
What startups/companies out there are using this kind of setup? What are some gotchas in terms of development speed, deployment, scalability, and integration?
(What would be helpful for me is personal experience or informal case studies. I'd like to de-priorities answers addressing alternatives like Grails or JRuby unless it turns out to be a big part of the equation)
Thanks!
I've never done any rails development but here are my thoughts. Why not just use Grails? I've done a fair amount of Grails development and it works well for rapid prototyping. It also offers all the power of Java, Spring, and Hibernate. Instead of dealing with communication between two different technologies you could take advantage of the fact that Grails uses Spring and Hibernate under the covers to deal with caching as well as any other requirements these technologies support. If you have Java developers Grails should not be to hard to pick up. The grails plugin story is decent. All of them are stored in a central place and are easy to obtain but quality differs depending on the plugin author. You also have to remember that since Grails uses Groovy which is syntactically similar to Java and runs on the JVM it is very easy to use existing java code including the multitude of available Java libraries. I don't know this for certain but I assume there are a lot more libraries out there for use with Java and there for with Grails then are available for the Ruby language and Rails. I can't make a resource usage call for you but my question would be how many people do you have with experience designing Rails systems that use Java on the back end with all the gotchas that will go along with that? You may find that you have no one who is proficient at debugging when something goes wrong in communication between the two technologies.
I have used similar pair for one of my projects, but instead of RoR I used Python. I don't think there's large difference.
In general, there's nothing specific in this kind of programming. Two most important things you must care about:
good modularity;
well thought-out protocol between RoR and Java.
First is about exact functionality decomposition between parts of the system. We've got some troubles because of not understanding what part of a job must be done by Java, and what part by Python. In general, you must tie together all functions that are close to each other, and thing that are far must be connected in a very few places. I guess you know rules of good modularity, but in case of composing different languages this must be thought-out much more carefully. You can also be interested in creating several distinct Java services (e.g. one for database caching and another one for all the rest) to be able freely combine them or even use in other projects later.
Second is about communication between your parts. I can see two ways to communicate: through database and through pure network protocol. The former need some network communication anyway, so we used pure network protocol, without any other way to connect parts.
We had experimented a lot with SOAP, but it gave hundreds of errors: this protocol is quite ok to connect services written in one language (i.d. Java to Java), but terrible for connecting services in different languages - automatic tools for generating WSDLs gave different results for Java and Python, and manual creating of scheme was hard and labor-intensive.
So we used to REST. It uses all the features of HTTP protocol such as all four main HTTP methods (POST, GET, PUT, DELETE), error codes and many other things, so it covers almost everything you may want. The only restriction with REST is that it can't hold state, so you may need to implement your own sessions mechanism.
If you're not very comfortable with REST and seek some real example, see Facebook Graph API and for implementing REST services in Java you can use Restlets.
Perhaps I'm stating the obvious here, but the biggest gotcha here is the actual fact you're combining two technologies. Not only will development be slower - Rails and all Java frameworks are expecting to have a full Ruby/Java application - but for the other issues you mention (deployment, scalability, integration), the existing tools and solutions will not work, or at least not very well.
If you have a compelling reason to combine the two, go ahead but expect to spend more time on these issues than with a single technology solution. If you don't, pick either Rails or Java.
I would strongly urge you to consider having the frontend and backend in the same JVM for performance reasons.
For Rails, JRuby can run Rails, and you can have it in a Java EE container providing fast communication between components.
Having multiple architechtures which do not run in the same process requires you to do network based communication which takes much, much longer than just passing a reference to an object (I do not expect you to want to use shared memory).
Twitter.com is supposedly using a Java backend, and Rails for their web interface. Here are some resources:
http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/
http://blog.adsdevshop.com/2008/05/02/twitter-is-not-abandoning-rails/
http://twitter.com/#!/ev/status/801530348
More specifically, they use Scala on the backend (which compiles to Java byte code):
http://www.artima.com/scalazine/articles/twitter_on_scala.html
I don't think there is anything wrong with this approach. However, you will be supporting two different platforms/VMs. I have seen this kind of situtation result in a sort of fracturing of expertise within an organization. And you end up paying to a lot to have two sets of expertise in house.
If the problem of segmenting expertise concerns you, I would suggest running JRuby of Rails. It is very mature now - and runs better than Rails on Ruby 1.8.x.
We have used Ruby on Rails for front-end and Core-Java SOAP Api for backend. It worked very well.
The main issue is not with performance but with the people. It is very difficult to hire expert people in Ruby on Rails for everything, instead you hire few or you can easily mould to just learn Rails UI.
As startup point of view, it is best strategy. So many believe ROR is best for startups... but very few knew it because in most of MNC's we use Java, so there is pressure to learn Rails and Code, or hire very few ROR developers. So instead you can use ROR for frontend (only few people do that, or it is easy to learn) and use experienced Java developers for DB updates and business logic.
I have used MS Money for several years now and due to my "coding interest" it would be great to know where to start learning the basics for programming such an application. Better to say: Its not about how to design and write an application, its about the "bank details". (Just displaying the amount of a certain bank account for the beginning would be a pleasant aim for me.).
I would like to do it in C++ or Java, since I'm used to these languages.
Will it be "too big" for a hobby project? I do not know much about all the security issues, the bank server interfaces/technique, etc.
At the first place after a "no" I need a reliable source for learning.
Most of the apps I've worked with read in a file exported from the bank's website, which is relatively straight forward.
If that's the road you're looking to go down you'll need to write code to:
Login to the bank's website to download the file via HTTPS
Either get specs for the file format or reverse engineer it
Apply whatever business rules you choose to the resulting data
The first thing to remember when trying to programmatically interact with a banking website without express written permission from the bank will MOST LIKELY be a violation of the website use agreement, and may land you in more trouble than it's worth.
Second, you DON'T want to start 'learning' programming by trying to tackle something that massive and sensitive. Not that there is anything wrong with the eventual goal, but that's a journey of a thousand leagues and you need to take your first step.
I would say start with a simple programming environment, like python, or perl. Reason, you don't have to worry about linking, libraries, code generation etc. Get used to the basics of what you want to achieve functionally, them reimplementing that in C++ or Java would be the next step.
To begin with focus on learning client-server programming.
Write a client, write a server, learn all about sockets, learn all about TCP programming,
then learning about secure socket layers (SSL) and transport layer security (TLS).
Once you've done this, try switching to C++ or Java and see if you can repeat the effect.
There are TONS of tutorials on these topics.
Once you have become used to that, learn what tools and libraries are already available to do most common things. For example libcurl is great for creating common internet application protocol clients (HTTP, HTTPS, FTP and the like).
See if you can create an interactive program that you can "log in to" using your web browser which outputs stuff in XML and formats it using cascading style sheets.
This should lead you into javascript world, where there are powerful tools such as jquery. If you mix and match these correctly, you will find that development can be a LOT of fun and quite rapid.
:-)
Happy journeying.
I think its quite a reasonable hobby project; start with a simple ledger and then you can add features.
A few things I would do to begin such a project:
Decide on an initial feature set. A good start might be just one of the ledgers/accounts - basically balancing a checkbook. Make this general enough that you can have several.
Design a data model. What fields will your ledger have? What restrictions on the values of each?
Choose technologies. What language do you want to program in? How will you persist the data? What GUI do you want - a fat client like MS money or a web app?
From there, write up some design notes if warranted and start coding!
You might look into OFX4J, an implementation of the Open Financial Exchange specification, mentioned here and in a comment by #nicerobot.
Are you looking for something mint.com-ish? From my understanding of their security policy this is how they do it: You give them your online account credentials which they give immediately to the bank and get back a "read-only" account login. They then throw away the credentials you provided and use "read-only" credentials to update your metrics every 24 hours. I don't know how they do this or if they have a special relationship with the banks, but it is possible.
I don't think many (if any) banks provides api's.
Online budget-apps in Sweden seem to rely either on exporting transactions in some excel format, or simply have you "mark all transacations in the banksystem, ctrl-c then ctrl-v in a textbox", which is then parses.
I'm looking for pointers to something that I may be overlooking (or maybe something that Jivebot hasn't yet written for me). What I want is a pre-rolled Java framework for managing user accounts that takes care of most of the common tasks associated with such.
For instance, Jfacets is a good approach to automagic view controlling, but you still have to roll the view code. I wonder if there's a framework that has pre-rolled components for inputting/storing common user profile information, sessioning, and possibly things like inter-account communication, connecting to common social APIs, exposing an API, etc. (basically some/all of the common tasks that a user profile-based app would want). It can be quick and dirty, this is a prototype app at the moment.
I do know that user profiles are a very app-specific arena, and that I may just have to build something up, just thought I'd check first.
In the absence of a pre-rolled solution, I like what I see in Woko after an initial glance (http://woko.wiki.sourceforge.net/). The preconfigured stack includes Hibernate, Spring, Compass, JFacets, Stripes, and Maven and an API framework. I may just need to build the prototype up leveraging this as much as possible.
Thanks
So, it looks like user profiles are just too situation specific for any framework. Shame, because there's a lot of basic functionality that could be served by a basic framework.
On the "solution" front, I'm attending the Open Source Bridge conference in Portland, Or. and recently saw topics on Scala (Two word description: Java scripting) and a framework built on that called Lift (three word description: CodeIgniter for Java). In short, these technologies rock my world.
Anyone looking for robust web frameworks should check out Lift. Scala allows people who love programming in Python and Ruby to use Java's JVM without the cost, with a lot of syntactic elegance (Scala is somewhat more intuitive to my Python-centric mind than Clojure). Lift is a MVC-style framework built on Scala which is just plain beautiful- and frighteningly easy to use.
Normal disclaimers, but the upshot is that it will take significantly less time to build an app-specific solution for a scalable Java app using these technologies than trying to find a user profile framework to use.