which technology to use for making a job hunting site
struts1,struts2,spring or simple servlet,jsp
which one runs faster as using a framework might slow you down.
struts1-> abstract class based -> so they should be faster than struts2 which are based on interfaces. (Anybody tested that if not how to test it.)
and about the spring i had no idea... it is said to be lightweight but what that terms actually means technically.
faster bean resolution or lesse libraries in which terms ...that "term lightweight" holds.
Use the one you are most familiar with. The technologies you mentioned are very generic/low-level, and not specific to a certain application such as a "job hunting website". The only slow-down you should worry about at this point is programmer productivity. If there really comes the time to do performance tuning later, this has probably nothing to do with how many bean classes and libraries need to be resolved, but with application (and database) design (on your end, not in the framework).
Related
I want to compare the performance of some web frameworks (Ruby on Rails and ASP MVC3) but I don't know how to get started... Should I measure how fast each framework renders e 10k long loop or how fast its renders 10k lines of html? Are there maybe programs that can help you with this? Also how can the server load be monitored? Any help is appreciated!
Thijs
With respect, this is an unanswerable question. Is a Porche faster than a Prius? Well, no, not when the Porche is in the shop :-).
The answer depends on what you're trying to accomplish, how you do it, and how you code it. For example, Rails goes out of its way to transparently cache as much as it can, and then makes it trivially easy to cache stuff on your command. Of course there's a way to do the same in ASP MVC3, but is it as easy?
Can you find, hire, and train a suitable team in that knows how to use the framework? What's the culture of the organization (Windows or Unix?). I could write a really fast application in MS-Access and the same application poorly in Rails against a high-performance database and the MS-Access app would win. It's far from a given that an application will be written well, optimized, or whatever.
These days, a well-written application is typically performance bound on data I/O, and if this is the case, then it's which database you use that might matter. The loop-test you propose would test almost nothing, unless you're writing an application that calculates pi to the billionth place, or something.
I am sure there are published benchmarks of application frameworks available, but again, they need to make assumptions about what the application actually has to do.
The reality is that any reasonable framework (which includes both of the two you mention) is likely to be as fast as necessary for most scenarios, and again, what you do, and how you architect and implement it are the far more likely culprits for performance problems.
Once you do choose, there's a great (awesome) tool called NewRelic RPM which works with several frameworks -- I use it with Rails, and it gives you internal metrics at a level of detail that is beyond belief.
I don't mean to be glib, or unhelpful. But this is a little bit of a sore spot for me -- in so many cases people say "we should use foo instead of bar because foo's faster", and weeks go by as bar is replaced by foo. And then there are little incompatibilities. And an unexpected bug. And then, well, for some reason the new one is a little slower. And then after it gets optimized, it's finally just as fast.
I'll step down from my soapbox now :-)
Seaside just released a release candidate for the upcoming 3.0 version, so it appeared on my radar again. As I'm currently pondering what web framework to use for a future project, I wonder whether it's something to consider. Alas, most of the publicity for Seaside is from '07, which is probably one or two generations for the web. So I'm hoping that the community here can answer some questions
Continuation-based frameworks were pretty great when most of your workflow was mostly in HTML, e.g. form submits. For today's JavaScript-heavy environments, that hardly seems worthwhile anymore.
Is Squeak able to handle a reasonable workload? From other questions here and elsewhere, it seems that for proper scaling another implementation (Gemstone etc.) would probably fare better in the long run, but I don't have a proper idea how far away that is. Sessions seem to be rather expensive.
I know that comparisons are hard, but most of the articles you find on the net set Seaside and Rails side by side. How would combinations like Scala/Lift, Clojure/Compojure or Erlang/Nitrogen do instead?
I have answers to question one and two:
This is true. However since version 2.8 Seaside is not a strictly "continuation-based" framework anymore. Seaside uses continuations in the flow module only. Since Seaside 3.0 the flow module is even optional. Also note that Seaside has strong Javascript support since 2005, this is long before mainstream frameworks started to add Javascript functionality. Today Seaside comes with JQuery and JQueryUI support built-in.
Of course that depends on what you store within your session objects, but typically sessions are small (less than 20 KiB). Use the memory profiler in your application to determine the exact memory consumption.
And there is a new seaside book: http://book.seaside.st/book
I find the productivity of working in a Smalltalk IDE with a good set of abstractions outweights all other issues in engineering dominated projects. It works well as an enterprise system for a small company with about 100 (simultaneous, but not heavy) users on a single server (without going to SSD). Since 2007:
Seaside has shown to be able to make the switch from html workflows to javascript ones;
Seaside has been ported to a lot of different Smalltalks;
Has seen Gemstone release GLASS;
The new 'cog' vm with much improved performance has been released a few weeks ago and shows great promise for improved performance.
In Smalltalk we have now three web frameworks to consider, besides Seaside also
Aida/Web and
Iliad.
Both later effectively solve three-like control flow, but without needing continuations. Both also have a very strong Ajax integration, actually you don't realize anymore that you are working with Ajax.
Both also scale in memory consumption well. 10.000 sessions spend 220MB in Aida/Web, that is about 23KB per session, which can be further optimized down to mere 400B per session. This means, that you can run not only but many websites from the single Smalltalk image. Of course you can always upgrade to load balancing solution, when you really need. Which is from my experience very rarely needed.
Comparing to Ruby on Rails, a friend of mine complained that he needs 50MB of memory initially for every webshop site he is selling. He then turned to the Aida/Web solution where he needs about the same MB for the image, but then just few KB for every additional webshop site.
Avi Bryant, the developer of Seaside, said that AJAX triumphs continuations in almost all situations. Nevertheless, you can build reasonably powerful applications with Seaside and AJAX, too.
The Application part of a Web-App can be done in other frameworks quite well using Ajax.
I think a Seaside integrated Smalltalk-to-Javascript Framework like Cappuccino-for-Clamato is missing, currently. I'd like to be able to build real Javascript-Apps using Smalltalk.
Javascript is awesome but being capable of dealing with complicated workflow in a clean cheap way in the server side (as Seaside allows you to) is preventing it to become obsolete. Economy and utility are things that gives return in the short and long run. But telling this in the abstract has no value at all. You should be talking about a precise application and deciding if seaside is part of your bunch of competitive advantages to form an equation that rocks (and knowing why).
About scaling workload with Seaside, the short answer is that you can scale it like hell yah (for the long answer check my answer here: Does Seaside scale?).
too unanswerable man :) rty a variation of what you're really trying to ask
I think the best thing you can do is a prototype of something in a weekend.
If you can do a prototype in two days and you can capture some attention and you enjoyed the developing experience of doing it with seaside then you'll have the foundation of your next thing.
It costs only your time (you can publish in an amazon server).
BTW, this week I've heard about a startup that made its prototype by hand (was everything static and they processed stuff manually). Pretty amazing and crazy and cheap. When they felt that they had enough traction on the idea (which the had) they implemented the app (with whatever tech, I'm sure is no challenge for a seaside developer)
I know this question has been asked before, but this was one and a half years ago, though I thought it might be the time for a re-questioning. I also recognized it might be seen as subjective, but I guess there are objective reasons for/against AOP.
I would be interested in who is using AOP in software development and also why or why not using it.
I see AOP as a very strong paradigm which can make a lot of development tasks easier. But when it comes to using AOP in real world projects I have made the experience that many decision makers are barely open to it. How did you manage to introduce AOP into your projects?
Previously asked question from August 2008: Do you use AOP (Aspect Oriented Programming) in production software?
Our managers listen to their architecture team.
We tell them that AOP is the only solution to implement cross-concern features:
at a reasonable cost in the first place
without messing with the functional code written by the development team
without ever forgetting (compared to manually adding a try-catch to thousands of methods), now and in the future
without having to train or control what the developers are doing (some are great, others are a real mess)
with a good maintainability
True, our project is 20 developers and lasted for several years, so there is a huge mass of code. It's the only solution.
I believe the key is to use it only for cross-cutting concerns.
If you can code it using regular code, do so. But if it is way too big, then AOP is attractive and justified. Failing to limit AOP would lead to hundred AOP little codes, that would be very hard to understand.
And yes, our software is production-software. Hundreds of clinics depend on it!
We don't use AOP 100% per se but yes we do use whenever we feel appropriate (mostly Spring AOP; that is so nicely integrated with Spring framework)
How did you manage to introduce AOP into your projects?
Well, separate out the cross cutting concerns eg. tracing method calls. In Spring AOP, you can define an aspect (a runtime behavior) which will get applied to a "hooked" section of code. With "hooked" I mean, you should be able to group all the methods where you need this behavior under one common umbrella. At runtime, this umbrella'ed code will get a new behaviour as defined by your aspect.
Spring AOP as Peakit said is easy to introduce if you are already using Spring framework in your project.
I first added AspectJ for our tools project that is only used internally and never released to customers. This helped both the development team and management to gain confidence on the tool and have a clear idea about what it can do for them.
I work for a large state government agency that is a tad behind the times. Our skill sets are outdated and budgetary freezes prevent any training or hiring of new employees/consultants (firing people is also impossible). Designing business objects, implementing design patterns, establishing code libraries and services, unit testing, source control, etc. are all things that you will not find being done here. We are as much of a 0 on the Joel Test as you can possibly get. The good news is that we can only go up from here!
We develop desktop CRUD applications (in C++, C#, or Java) that hit the Oracle database directly through an ODBC connection. We basically have GUI's littered with SQL statements and patchwork code. We have been told to move towards a service-oriented n-tier architecture to prevent direct access to the database and remove the Oracle Client need on user machines.
Is WCF the path we should be headed down? We've done a few of the n-tier application walkthroughs (like this one) and they seem easy to implement, but we just don't know enough to understand if we are even considering the right technologies. Utilizing the .NET generated typed DataSets seems like a nice stopgap to save us month/years of work (as opposed to creating new business objects from the ground up for numerous projects). Is this canned approach viable for a first step?
I recently started using WCF services for my Data Layer in some web applications and I must say, it's frustrating at the beginning (the first week or so), but it is totally worth it once the code is deployed.
You should first try it out with a small existing app, or maybe a proof of concept to make sure it will fit your needs.
From the description of the environment you are in, I'm sure you'll realize the benefit almost immediately.
The last company I worked for chose WCF for almost the exact reason you describe above. There is lots of good documentation and books for WCF, its relatively easy to get working, and WCF supports a lot of configuration options.
There can be some headaches when you start trying to bend WCF to work in a way not specifically designed out of the box. These are generally configuration issues. But sites like this or IDesign can help you through those.
First of all, I would definitely not (sorry for the emphasis) worry about the time you'll save using typed DataSet's versus creating your own business objects. That is usually not where you will spend most of your development time. I prefer using business objects myself.
In you're situation I would want to implement a proof-of-concept first. One that addresses all issues you may encounter. This proof-of-concept should implement an entire use case, starting on the client, retrieving data from the database and returning it to the client. You should feel confident about your implementation before continuing.
Then about choice of technology. WCF is definitely a good choice for communication between your client applications and the service layer. I suppose that both your clients as well as your service layer will become C# applications? That makes things a lot easier since interoperability between different platforms (Java/C# for example) is still not trivial although it should work in most cases.
Take a look at Entity Framework (as there are a couple Oracle providers available for it already) in conjunction with .NET 3.5 SP1 which enables built-in WCF serialization of your EF generated classes.
Here is a good blog to get started: http://blogs.msdn.com/dsimmons
CSLA might be a good fit for your N-Tier desktop apps. It supports WCF, has a large dev community, and is well documented. It is very object oriented.
AOP is an interesting programming paradigm in my opinion. However, there haven't been discussions about it yet here on stackoverflow (at least I couldn't find them). What do you think about it in general? Do you use AOP in your projects? Or do you think it's rather a niche technology that won't be around for a long time or won't make it into the mainstream (like OOP did, at least in theory ;))?
If you do use AOP then please let us know which tools you use as well. Thanks!
Python supports AOP by letting you dynamically modify its classes at runtime (which in Python is typically called monkeypatching rather than AOP). Here are some of my AOP use cases:
I have a website in which every page is generated by a Python function. I'd like to take a class and make all of the webpages generated by that class password-protected. AOP comes to the rescue; before each function is called, I do the appropriate session checking and redirect if necessary.
I'd like to do some logging and profiling on a bunch of functions in my program during its actual usage. AOP lets me calculate timing and print data to log files without actually modifying any of these functions.
I have a module or class full of non-thread-safe functions and I find myself using it in some multi-threaded code. Some AOP adds locking around these function calls without having to go into the library and change anything.
This kind of thing doesn't come up very often, but whenever it does, monkeypatching is VERY useful. Python also has decorators which implement the Decorator design pattern (http://en.wikipedia.org/wiki/Decorator_pattern) to accomplish similar things.
Note that dynamically modifying classes can also let you work around bugs or add features to a third-party library without actually having to modify that library. I almost never need to do this, but the few times it's come up it's been incredibly useful.
Yes.
Orthogonal concerns, like security, are best done with AOP-style interception. Whether that is done automatically (through something like a dependency injection container) or manually is unimportant to the end goal.
One example: the "before/after" attributes in xUnit.net (an open source project I run) are a form of AOP-style method interception. You decorate your test methods with these attributes, and just before and after that test method runs, your code is called. It can be used for things like setting up a database and rolling back the results, changing the security context in which the test runs, etc.
Another example: the filter attributes in ASP.NET MVC also act like specialized AOP-style method interceptors. One, for instance, allows you to say how unhandled errors should be treated, if they happen in your action method.
Many dependency injection containers, including Castle Windsor and Unity, support this behavior either "in the box" or through the use of extensions.
I don't understand how one can handle cross-cutting concerns like logging, security, transaction management, exception-handling in a clean fashion without using AOP.
Anyone using the Spring framework (probably about 50% of Java enterprise developers) is using AOP whether they know it or not.
At Terracotta we use AOP and bytecode instrumentation pretty extensively to integrate with and instrument third-party software. For example, our Spring intergration is accomplished in large part by using aspectwerkz. In a nutshell, we need to intercept calls to Spring beans and bean factories at various points in order to cluster them.
So AOP can be useful for integrating with third party code that can't otherwise be modified. However, we've found there is a huge pitfall - if possible, only use the third party public API in your join points, otherwise you risk having your code broken by a change to some private method in the next minor release, and it becomes a maintenance nightmare.
AOP and transaction demarcation is a match made in heaven. We use Spring AOP #Transaction annotations, it makes for easier and more intuitive tx-demarcation than I've ever seen anywhere else.
We used aspectJ in one of my big projects for quite some time. The project was made up of several web services, each with several functions, which was the front end for a complicated document processing/querying system. Somewhere around 75k lines of code. We used aspects for two relatively minor pieces of functionality.
First was tracing application flow. We created an aspect that ran before and after each function call to print out "entered 'function'" and "exited 'function'". With the function selector thing (pointcut maybe? I don't remember the right name) we were able to use this as a debugging tool, selecting only functions that we wanted to trace at a given time. This was a really nice use for aspects in our project.
The second thing we did was application specific metrics. We put aspects around our web service methods to capture timing, object information, etc. and dump the results in a database. This was nice because we could capture this information, but still keep all of that capture code separate from the "real" code that did the work.
I've read about some nice solutions that aspects can bring to the table, but I'm still not convinced that they can really do anything that you couldn't do (maybe better) with "normal" technology. For example, I couldn't think of any major feature or functionality that any of our projects needed that couldn't be done just as easily without aspects - where I've found aspects useful are the kind of minor things that I've mentioned.
I use AOP heavily in my C# applications. I'm not a huge fan of having to use Attributes, so I used Castle DynamicProxy and Boo to apply aspects at runtime without polluting my code
We use AOP in our session facade to provide a consistent framework for our customers to customize our application. This allows us to expose a single point of customization without having to add manual hook support in for each method.
Additionally, AOP provides a single point of configuration for additional transaction setup and teardown, and the usual logging things. All told, much more maintainable than doing all of this by hand.
The main application I work on includes a script host. AOP allows the host to examine the properties of a script before deciding whether or not to load the script into the Application Domain. Since some of the scripts are quite cumbersome, this makes for much faster loading at run-time.
We also use and plan to use a significant number of attributes for things like compiler control, flow control and in-IDE debugging, which do not need to be part of the final distributed application.
We use PostSharp for our AOP solution. We have caching, error handling, and database retry aspects that we currently use and are in the process of making our security checks an Aspect.
Works great for us. Developers really do like the separation of concerns. The Architects really like having the platform level logic consolidated in one location.
The PostSharp library is a post compiler that does the injection of the code. It has a library of pre-defined intercepts that are brain dead easy to implement. It feels like wiring in event handlers.
Yes, we do use AOP in application programming . I preferably use AspectJ for integrating aop in my Spring applications. Have a look at this article for getting a broader prospective for the same.
http://codemodeweb.blogspot.in/2018/03/spring-aop-and-aspectj-framework.html