I've used ZeroMQ in the past with with JVM applications via the jzmq library. I am planning on using zeromq on a new project where some of the services are implemented on the JVM. I just discovered jeromq, a pure java implementation of zeromq, and I would like to use it mostly since it is tracking zeromq 3.x and it removes the headache of dealing with jzmq. However, I can't tell from the repo page if it is production ready. Does anyone have experience with jeromq in production?
As the author of the project, I'm a little bit biased.
The reason I made jeromq was I also had some trouble with deploying jzmq having JNI.
The project has a short history but keep improving from feedbacks and contributions.
But it's not a replacement of jzmq. Both project are active and driven by a major community. You can get help from the community and contribute to the projects also.
From the 3.0-SNAPSHOT, it has a API level compatibility. You can switch between jeromq and jzmq easily without changing your code.
Why not write a JNI that would do all the interaction with 0MQ ? This would bring the problem in your hands instead of hoping for some 3rd party library being mature enough or production-ready.
That's what I'd do. The C/C++ API of zeromq is IMHO the most mature of them and, as such, I think it would bring you the most benefit.
Writing a JNI is not hard either so I think this would be a good way to go.
I'm on my way of getting a decent programmer but it seems that the things there are to learn are countless. I know that there's never a certain answer when one ask which is better, but I'll try to make my question more specific hoping for a more certain answer.
I'm using/working with PHP for a year now. Starting from the most simple examples, now I'm using CodeIgniter and various libraries/frameworks for the frontend and I feel like I need to make a step ahead, which in my case is learning another PHP framework - Symfony2 and also, because I'm getting my masters degree on "Software technologies" now and there I intensively use Java, I want to try and start learning both - Symfony2 and Spring. Among the many questions how to accomplish that without ending with just a lost time, the usage of XML, YML is something where I see an option for getting an edge in my work.
Java is heavily XML, and as far as I know, there's no escaping from XML in Java. But in Symfony2 one have a choice and it's very tempting to use XML there so I won't need to learn one more thing among all others but most of the examples I see for Symfony2 use YML and I'm not very sure that skipping yml and trying to stick strictly to XML won't turns back on me.
I'm not experienced neither in Spring or Symfony so if it was you learning both of them at a time how would you approach? Using XML for both, or using YML for Symfony2?
I'm making my money as a Symfony developer, while developing my personal project in Spring MVC, so, since I've seen the both worlds, I think I have something to share on this topic.
I'm developing in PHP for like 7 years, and I know Java as a language for like 5 years, but I'm developing my first “real” Java project just for a month or two. Eventually, I want to ditch PHP for good and switch to Java and/or other JVM languages like Scala.
What's the reasoning for this? Well, don't get me wrong, Symfony2 is a great framework and I really love it. I believe it's the best PHP framework out there. But... it's still PHP, you know. No matter how great a PHP framework is, I just can't stand PHP as a language for too long. What's so wrong with PHP, you ask? There is a great article explaining exactly what I've been feeling about it for a long time (at least read the analogy section).
And since I prefer static binding and strong typing, I'm more comfortable with Java for this reason too. It's just so great what a Java IDE does compared to what the best PHP IDE does. I think I'm using the best IDEs for these languages out there — IDEA (with the PHP plugin) or PhpStorm — and Java support is just so much better it makes me want to dance.
I'm not saying that Java is the greatest language of all, but it's a huge improvement over PHP. I think Scala is very promising, but since its infrastucture/ecosystem is not mature enough for me — a pragmatic who likes to get the end-user projects done, compared to guys hacking the languages themselves and developing frameworks — I'm staying with Java for now.
So, for me it boils down to the language, community and ecosystem. While the PHP community has some great developers and I enjoy having conversations with them on IRC or other places, the Java community has much, much more great developers developing much, much more great stuff for the much, much bigger Java ecosystem.
Apart from those 3 things, I could add that Symfony is much easier to learn — its book and cookbook are great and really to the point, while I have to hunt down a lot of information about Spring in numerous books, blogs and its vast documentation.
Speaking of YML and XML, you can do a Symfony project in XML only, and you can do a Spring project completely or almost completely without XML — especially since version 3.1. I use YML in my Symfony projects but XML for bundles I share.
And since Symfony DIC and security are based on Spring and Spring Security, and Doctrine is based on JPA, learning idioms of one of these frameworks, you learn a lot about the other one. What I'm really missing is a Twig analog in the Spring MVC world — JSP gets the job done, but it's not that great. I know there are other view technologies Spring MVC integrates with, but to me it seems like JSP is the most endorsed one.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How do the major C# DI/IoC frameworks compare?
There being so many DI containers, I feel kind of lost. I'm new to the DI pattern.
I'm reading the book Dependency Injection in .NET and I've found DI to be incredible useful in improving a code base, making it loose coupled and more testable.
I now want to introduce a DI container for my dummy project, but there are just so many to choose from.
How am I supposed to choose between Castle Windsor, Unity, StructureMap, Spring.NET, Autofac, Ninject, Funq, LinFu, etc, etc?
I guess a coherent take would be to "just pick one" and start using it (since I figure they're pretty easily interchangeable, specially in the early stages), but I would like to make a more informed decision.
This is like buying a car. You might like a Toyota, but it's just 2.5L engine. You might like Ferrari, but it's too red. You might like Mazda, but your boss doesn't allow you to drive it. You might like Hummer, but then your colleagues would laugh at you. Mix the manufacturers to your taste, there's always going to be something missing for somebody or at some different moment.
My take is - first and foremost, DI is usually better then not having DI. Pick anything and you'll be better off. I'd pick something that:
Has good support in community (so you can get answers)
Has a good backing company behind it (so you don't get to rewrite your code when it goes bust)
Feels good to you (so you don't swear in front of the kids, not cool)
Is not an overkill for the project
Is not just DI, but offers an ecosystem of things that will reduce the time you spend on tasks that you know you can do, just not right now - and then you can focus on things that matter
Is used by a lot of people (so you know that many parts are also tested in real life and bugs filled)
Isn't 5 years old (such as that documentation says it is supported on Windows 98 or something)
My 2 cents - http://www.springframework.net/. I mean, their documentation contents page is like 20 pages long...
Or you just might want to look at some more answers to a similar question:
Which .NET Dependency Injection frameworks are worth looking into?
You can start with the builtin DependencyResolver in MVC3. Later you can easily upgrade to Enterprise Library Unity DI.
Brad Wilson had mentioned a series of posts on How to use DI in MVC3.
My stance is, look at a few - you got the excellent "Dependency Injection in .NET" book already (to that list I would add Ninject, which unfortunately is not covered in the book) - and pick one of them that you understand the best and like the syntax. To get started with advanced features are not really important, just that you do start.
Once you have a IoC container, replacing it should be mostly trivial since all your changes will be in one spot - the aggregate root - and not spread out all over your code base. Using an IoC container will also force you to design for dependency injection if you have not already, that will be the much bigger impact on your projects.
I've been using Ninject and Unity. When you add Unity MVC to Unity, then the code reminds me of the Ninject code.
Both are very easy to implement. Both allow substitution of being config file centric with a launcher class centricity.
I suggest create a 2 hour project, and implement it in each of the ioc di frameworks, and decide by experience which one you like. However, if you do this without looking at other features you may find that you missed something. So do look at periferal features, such as 3rd party support.
In addition to the other great comments - if you install the Unity.MVC3 package, just beware you have to use HierarchicalLifetimeManager if you want your objects disposed with each request. Its worked great but I think you'll find in most cases all the major ones are quite nice.
The question for you is to find one that fits into your environment. Some places allow open source, some dont and in those cases Unity wins out.
The most developed DI container for .NET is Managed Extensibility Framework (MEF) and I strongly recommend to use it. MEF is fast, easy and maintainable across the team together with a perfect learning curve.
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 3 years ago.
Improve this question
So, I've got an idea for a website. I can start off using any platform and frameworks I want, but there are almost too many options.
OS Platform:
Windows, *nix
Web Framework:
Rails, ASP.NET, ASP.NET MVC, Django, Zend, Cake, others
Hosting:
EC2, Dedicated Server, Shared Hosting, VPS, App Engine, Azure, others
Persistence:
S3, MySql, PostreSql, Sql Server, SimpleDB, CouchDB, others
How do you avoid decision paralysis and get started?
Firstly, your familiarity with a framework's language should dictate which framework you choose. Don't add the burden of learning another language on top of learning a framework.
Next, have a look at the remaining frameworks. Do they have good documentation? What about the community. (A good community can go a long way to making up any shortcomings of a given technology.) Does the framework solve the problems that you need solved?
Finally, just dive in and try something! Pick the one that makes the most sense to you and start writing code. Don't do too much hand-wringing over your decision. If it becomes obvious that you made the wrong choice, it should be obvious quite early. Learn from what you've accomplished so far and consider restarting with a different technology. (Just don't get several weeks down the road before you make this decision!)
I'm sure you don't like all of those technologies equally. Pick a framework that you like and get to work.
It depends on what your app is going to be doing. A handful of the technologies you listed are direct competitors (like Django vs. Rails), but some are completely different ways to do things (like MySQL vs. S3).
Questions to answer before you begin:
Will the app need to be horizontally partitioned in the near term? If so, using EC2, Google App Engine or Azure would be a good option.
Will your app fit into the constraints of Google App Engine? If so, it requires a lot less hassle on your part than running on bare metal (whether real or virtual).
What's your preferred web framework? If you want an MS framework, you'll need to run on a host that supports that.
What will your persistence and data access patterns look like? This will determine whether to use a database or something more exotic.
If you are running on EC2, the other AWS services are more appealing. Similarly, if you are using GAE, you have only one option for persistence. If you are using Rails, may as well start with MySQL.
In answer to your question of how to reduce the number of options, the answer is to realize that many of the options are related, so you don't have as many choices to make as it first appears.
Some advice that was once given to me is, pick what your friends (or colleagues) are using. Having people around you that you can share ideas and the learning experience with is invaluable.
If you want to learn something new: I'd just go with your gut and get started. If it sucks then switch to something more familiar.
If you don't have much time: Go with what you know and forget about the other options. Just start coding.
Optimize for happiness. Pick the one that you like the most. Or the one that intrigues you the most.
I've worked in Microsoft shops, in Ruby on Rails, and in homegrown shops having Apache, Jetty, even Mason.
All frameworks have their warts, their idiosyncracies that will keep you up until 3 AM, and their "tribal knowledge" vagaries that will be completely unexportable to other frameworks. (The last point is sometimes by design, the whole "platform entrenchment" business strategy)
Listen to what the supporters of the frameworks say about the problems with the other frameworks (Google: X framework vs Y framework). Pick the framework that has the loudest supporters. If they are equally loud, make the decision with a dice roll.
With me it's simple.
I only know MS stack and see no point in "checking out" all of those you mentioned.
No, actually I once tried to use JSF before excluding it from my list permanently.
Use what you are experienced in and where you can be more productive. The objective is to get your site up and running. Go for it.
One of the biggest factors in determining which platform/framework to use is your budget. You have to factor in the cost of licensing, software required to develop/maintain your website and other miscellaneous costs.
I suggest you begin with a scorecard of your own construction. Perhaps you can find different ones on the web, but if you do, modify them to meet YOUR needs. There should be a scorecard for each level in the stack (as you've described). Each scorecard should share some aspects to grade with other scorecards but each will also have their unique aspects.
Once constructed, weight each aspect graded according to your needs.
Once you've chosen the weights, pick the scales for grades.
At this point promise yourself you wont mess with the weights or the scale and then start collecting data on your options for each level in the stack.
You may also want to put a time limit on the collection period.
Make your decision based on the outcome of the scorecard.
The beauty of this approach is that the effort is made in constructing the scorecard, not in circular arguments of options. The effort in making the scorecard is vendor agnostic and focuses on the desired result, not the options. Thus you can avoid paralysis.
One more thing, my best scorecards have included sections addressing the availability of resources and other human related things. Don't make the mistake of just looking at the technology.
good luck.
Go for personal preferences.
One decision at a time:
Firts I would begin with type of language:
Script: PHP, Python,
Serious: Java, .Net
The language will restrict your OS, plattform and will give you hints for the dataabse decission. The database load is also important. And, Do you want logic in the DDBB? how much data?
Last advice. Try combinations well tested. LAMP, WAMP, Windows with SQL Server and .NET.
Evaluate each platform and technology for quality of tools for your needs. For example, if you are cost sensitive, you would value free operating systems and tools higher than costly ones. If you need performance, you would value tools which provide high performance higher than ones that don't.
It entirely depends on your situation. I spent several months evaluating stuff for a new commercial web site last year, and it was very easy to feel paralized. In the end it was talking to several people who'd done similar things, and of course reading a lot of stuff online and from Amazon. I chose Java, since our team had a lot of experience in it, and it has good performance and extensive supporting technologies. Oracle is our database but we used a persistence manager to make it easy to change later on. We used a half-dozen very good libraries to eliminate much of the boring and repetitive coding (Restlet, iBatis, Freemarker, XStream, jQuery, SLF4J). We used Glassfish as our web server.
Yours sounds like a small project with only you to work on it. In that case, pick a complete framework instead of a smorgasbord like we did. Pick something fun to work with, and something with good "return on resume". Look very hard at Ruby on Rails, Django (kind of a Python on Rails), and Groovy on Grails (a Rails-wannabe for the Java world). In your shoes I'd pick Ruby on Rails because there's a large and growing community and a good number of books and tutorials. Plus, Ruby looks like a worthwhile language to learn. For your database, just pick one. These frameworks make it easy to change your mind later. Pick MySQL unless you have another you like better.
And as other posters said, just do it! ;-)
Like others said, pick something you and your employees are familiar with. I highly doubt you are close to being industry ready with all those techs.
OS Platform: Windows, *nix
Shouldn't matter except for Windows licensing costs, and that is probably the least of your expenses.
Web Framework: Rails, ASP.NET, ASP.NET MVC, Django, Zend, Cake, others
Dependent on your favorite language
Hosting: EC2, Dedicated Server, Shared Hosting, VPS, App Engine, Azure, others
You should design your product to be movable, so you can scale among these. If you know for sure you are going big, then just start off with EC2. App Engine is extremely limiting, ex. they don't let you form outbound connections.
Persistence: S3, MySql, PostreSql, Sql Server, SimpleDB, CouchDB, others
You need to do the research yourself whether or not your product requires an RDBMS or a simple key/value store, and what features each of these have.
Just go for it! Your platform choice really is not all that important as long as you make a reasonable choice (Ruby + Rails, Python + Django, PHP + Cake/CodeIgniter). Any of these can be used to build successful sites. If your site really takes off, you'll be able to scale it fine.