norman richards

Author
+ Follow
since Jul 21, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by norman richards

I'd also point out that Clojure aggressively clears local variables when it can so that things can be garbage collected as soon as possible.
11 years ago
At a recent Austin Clojure Meetup someone demonstrated JavaFX integration, showing building and updating a UI from the repl. I don't do enough desktop app work to compare it to Seesaw, but it was quite interesting.
11 years ago

qunfeng wang wrote:I have 2 questions.

1. What's Clojure good at comparing with other languages?
2. How about the Clojure language in industry? Are there any companies use Clojure in their projects?




Clojure is a general purpose language. It's very good at everything. Based on my observations, it seems to be used for web applications, long running services, analysis tasks and tools, which is pretty much everything you'd be likely to code these days. That's not to say it's not used effectively for other things - I'm just mentally organizing what I see it commonly used for now.

I am working for a company that uses Clojure. We have a web application in Clojure and Clojurescript, and our analysis engine is in Clojure using core.logic. What I personally really love about this choice is because of the flexibility and expressiveness of Clojure (especially with core.logic) we can pack a lot of power in very little code. We can get by with a smaller team and we effect changes in the system much more quickly than I've experienced with other similarly sized projects.

I also really love how easy it is to write Clojure. Nobody was more skeptical of lisp-syntax than me, but structured editing (paredit) along with a connected live REPL is insanely powerful. I find it more productive than both Java with it's powerful IDEs and languages like Ruby and Python with their already rapid and flexible development models.

11 years ago
Why I'll be in line for an iPhone:

1 - It looks like a great phone. I've hated almost every phone I've used. In general, they all work the same and they all work quite poorly. The iPhone designers appear to have put a lot of effort into making a phone that is really good at making and receiving calls. It looks like a phone that I won't hate to use.
2 - Visual voice mail. Yes, voice mail is a real pain. Fortunately, I generally only have 2 or 3 queued up, but even there it's a real pain to have to sort through them. Finally someone took the time to get voice mail right.
3 - Good text messaging. Truthfully, I spend more time text messaging than making voice calls. The iPhone gives an IM-style interface to chat, which I think is brilliant.
4 - Fully functional syncing. My motorola syncs, but it can't handle pictures. My Nokia could, but it got other things wrong. Since apple owns the entire cycle, I believe they can get syncing right.
5 - I can get rid of my iPod. I'll only need to carry one device now. Hooray!
6 - Internet access. I lug my laptop EVERYWHERE, but generally I really only need web and email access. The iPhone looks like it provides a quality web and email experience which will let me leave my laptop behind most of the time.

So, when you add it all up, the iPhone is any easy buy for me. It promises to solve many problems I have now. (not to mention the features that aren't direct needs/wants, but are still really cool) There's no guarantee that it will work as well as it looks like it does, but I'm willing to bet that it does based on Apple's track record.
17 years ago
I think "JBoss: A Developer's Notebook" is a great JBoss book if you are trying to learn how to use JBoss and are already familiar with EE programming.
17 years ago
I think "JBoss: A Developer's Notebook" is a great JBoss book if you are trying to learn how to use JBoss and are already familiar with EE programming.
17 years ago
I think "JBoss: A Developer's Notebook" is a great JBoss book if you are trying to learn how to use JBoss and are already familiar with EE programming.
When starting Seam, we actually looked around at the various web frameworks. JSF was ultimately chosen because:

It is a standard.
It has an extremely powerful and flexible request/response model that provides what we need for complex features like conversations and intelligently-managed persistence/tx
It supports a component-based development model. Not only is it simpler and more powerful than action-based frameworks, it has a lot of potential for tooling.

However, Seam really doesn't have to use JSF. It's entirely possible for someone to decide they would rather use a different web framework and to write the integration bits for that framework. I don't foresee that happening because JSF turns out to work really well in practice, at least in the context of Seam where we have already taken the rough edges out.
More importantly, we have always intended Seam as a way to advance the standards. Somebody has to develop the technology that tomorrow's standards are based on, right? Seam has already had a huge impact on EJB3 (many things in EJB3 were designed the way they were specifically to support the ideas Gavin had for Seam). We have spearheaded big changes in JSF and in the next round of EE 5 specs. And, of course, don't forget about the WebBeans JSR.

So yes, Seam is too big for just JBoss. We've never seen this a proprietary technology (think spring) but as something that will pave the way for future EE standards.
Spring web flow is functionally very close to jbpm pageflow. If you are only looking for the functionality of spring web flow, then you'll be very happy with Seam.
JBoss 5 has introduced some features which break compatibility with some of things we are doing in Seam. We'll definitely be making it work, but until JBoss 5 is a bit closer to final, it's not a huge priority.

That being said, if you wanted to contribute a fix now, I'll make sure it gets into Seam 1.3.
What do you mean "cannot catch" it? JBoss certainly throws it and it doesn't get caught by anything else. Here's a method I wrote just last week:



I this is the case because I forgot to think about the case when the application starts and there are no inventory items to sum. I was getting EntityNotFoundExceptions.
[ July 26, 2005: Message edited by: norman richards ]
19 years ago
Finder methods must start with "find", so change your method name to "findAll".
19 years ago
The J2EE 2 spec never intended that applications be deployable without vendor specific deployment options. That you may be able to do this in many cases is entirely coincidental. It might even appear to be working, but if you are doing anything with security or any number of other un/under-defined aspects of J2EE apps, your deployment won't make sense.

The reason this is working in this case is most likely that the ejb-links are fully resolving the bean and there is no need for the explicit JNDI name mappingd in the jboss.xml.