Funny Quote

Micro$oft is the blunt of many a joke these days, but this one made me chuckle out loud:

"The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge

[found here - a useful page in its own right]

Why not Casual Monday?

American workforce culture is already too focused on getting to the weekend - Casual Friday makes it worse.

So I'm in the second week of working at yet another new job. It is a pretty good sized company (though nothing like the behemoth that was HSBC), and as is the norm they observe a "business casual" dress policy, including "casual Fridays " where jeans are acceptable. It got me thinking this morning as I donned my most comfortable denim: why is it always Friday that companies (the ones that are still enslaved by the idea that dressing in khaki's and golf shirts 4 days out of the week somehow makes people better workers) designate for "casual" attire? Why not Mondays?

I mean, it is already the sad state of the typical American worker mentality that so many see Friday as a kind of Elysian Field , a reward for surviving the rigors of the work-week. I find that "work for the weekend" attitude very revealing and pretty pathetic; it says a lot about the typical worker's attitude towards his job, satisfaction with his work, and the typical company's treatment of employees, that so many people are so focused on the nearing reprieve (Friday) instead of on what they can accomplish during the week. So when I see Friday accentuated as a partial release of our workplace burdens (in the form of a relaxed dress policy), I can't help but think it is just reinforcing the "work for the weekend" attitude: "I can't wait until the weekend so much that getting to wear casual clothes on Friday is a big deal."

Thus, I wonder why companies don't use the carrot of Designated Casual Dress to entice workers to look forward to Monday or even Wednesday. Who among us does not regularly loathe Mondays, dreading the return to the drudgery of the work week? Alternatively, how far would Casual Wednesday go towards wiping out the thought of Wednesday as Hump Day ? If employers offered Casual Monday (or Wednesday), would that not make those otherwise barely tolerable days that much more palatable?

Imagine waking up on Monday morning and being able to slip into those old comfy jeans and tee-shirt. Doesn't that make Monday at least a little better? Wouldn't that help fend off those draining attacks of Mondayitis ? I think it would.

Reaction to Sun's open source release of Java

It's been inevitable for quite a while now, and this week Sun finally officially announced the open-source plan for Java. Let me take this opportunity to log my personal reaction to this "long time coming" news:
Yaaaaaaaawwwwwn

As far as I saw, the only people who complained about Java not being "open" were the frothing-at-the-mouth FOSS zealots (OK, I'm going to get some flames for that word choice - but I have a soft spot for the overly-dramatic, so it will stay).
Let's be honest: the critical parts of Java, the libraries and reference implementations and compatibility test kits, have been source-available from the beginning. I just don't see a lot of people caring that the JVM and compiler are open now.
Actually, now that I think about it, I take back the yawn. I am very interested, because I'm now concerned that Sun does not have enough influence any more to keep Java from fracturing. We have to hope that the community can restrain itself to keep that from happening - but I would not bet on that. Maybe some other big players like IBM will be able to police the renegades who want this or that little thing and, when they can't convince the rest of the community, go off and create MyJava.
The last thing Java needs right now is to become the next Linux, where binaries aren't compatible and users of one distro can barely find standard file locations on other distros.

Julian at 4 months old

Julian is 4 and 1/2 months now, and September was quite a busy month for him.

There were road trips:

• to Miami to see his Abuela and Abuelo and meet the Miami chapter of the Official Julian Fan Club
  
• to Sanibel to celebrate his great-grandpa's 80th birthday. It was Grandpa's birthday, but Julian kind of stole the show - so many great-aunts and great-uncles and second-cousins, so little time!

He also had his first adventures into the swimming pool. He was skeptical at first but seemed to enjoy it after a while.

Last night he spent his first night away from Mom and Dad - Poppy and Nonni (Jerry and Marilynn) had babysitting duties for the night. We were lonely and wondered how he'd handle himself, but the report came back great.

There's lots of new pictures from September at http://www.rizzoweb.com/photos/Julian (including the road trips to Miami and Sanibel).
We have also uploaded all his photos to Walgreens web site so you can order prints and pick them up at any Walgreens store: click here to see them . You will have to create a free account at the Walgreens website in order to see them and order prints. Email us if you have any trouble.

Enjoy,
Eric and Jazmine

Update on Julian at 3+ months old

We've put up new pictures of Julian from July and August.
http://www.rizzoweb.com/photos/Julian
He is growing so fast you won't recognize him. Last week he was 15.5 pounds and over 25 inches long - 90th percentile on the growth charts for his age!
Julian will be 15 weeks old this week. He has started rolling over on his own, and really interacts with people around him - smiling, cooing, laughing. Last week he started sleeping almost completely through the night (a big relief for his parents :-)
This week we started him at a babysitter during the days - it is hard for us to leave him but this is a big step for him. Pray for us!

The Truth About Infants

Everyone gives all kinds of advice when you are expecting a child. Our least favorite (mostly because it is so dully predictable) is "Your life will change forever" (For a while Jazmine and I were counting how many people said that to us, trying not to roll our eyes each time). Well, Duh! Of course it is going to change - that is one of the reasons people choose to have children, isn't it?
Anyway, lots of people tell expecting parents how much babys like to eat, sleep, and poop. That's pretty much all they do.
But the thing that nobody actually pointed out was this important truth: In addition to eating lots of breast milk and formula, infants gobble up huge chunks of time, taking it up in surprisingly large gulps, until your entire day has been devoured by this little 11-pound time-eating machine.

This seldom-expressed truth is probably the most surprising thing about having Julian for us thus far - I'm sure there will be others, but right now it seems like every day it is 3:30pm by the time we blink, and then it is 10:30 at night before we take a breath. God help us... :-)

I Have Arrived!

Hi, I'm Julian Isaac Rizzo, the newest member of the Rizzo clan.

Click here to see more pictures of my exquisite handsomeness

I came aboard Thursday May 25 at 8:25am, carrying 8 pounds 9 ounces and 20 inches of adorable little ears, chins, arms bottom and toes.
I'm a little busy learning to forage for food and figuring out this whole night and day thing, so this is all I can write for now. I'll dictate some more notes later for Daddy to type.

Adios,
Julian

Signs of things to come

I guess this is the kind of little scene we are going to have to get used to around the house - we woke up yesterday morning and discovered our laundry rack had been infested with these miniature clothes.

There's a lot of laundry, and this baby isn't even here yet!

The Spectrum of "Web Services"

In response to a recent question about a company wanting to jump into the web services pool, I wanted to give some publicity to John Udell's musings on the nature of web services, particularly his notion of WS-Heavy and WS-Lite.

Victor Grazi wrote:

"Our company is interested in exposing some of our server java api as web services. 2 years ago that would have probably meant introducing an ejb framework and wrapping those as web services. I would be interested in hearing other approaches. Any ideas?"

The first question to ask is whether you're interested in going down the WS-* path or the "Web 2.0" path. In other words, are you interested in being WS-Heavy or WS-Lite? (see http://weblog.infoworld.com/udell/2005/09/21.html and the links from that page).
Mica's Hotels.com architecture sounds like it lives towards the WS-Lite/Web 2.0 end of that spectrum, while SOAP, UDDI, WS-I, etc. would put you more towards the WS-Heavy end.

Once you understand that distinction and determine which end you need/want to live near, then you can decide on the technologies to implement those choices.

So THIS is what the world looks like before 7:00am

Out of character, I was out of bed before 7:00am last week. It just so happened to be the coldest morning we've had this winter, and I captured the icy beauty on film. Well, not really on film, since in this age of digital photography my Fujifilm S5000 doesn't use that old-school medium.

Anyway, I was rewarded for my efforts at this un-Godly hour - the air was so cold (about 26 or 27 degrees, which is pretty darn cold here on Florida's west coast) that steam floated gently up from the pond behind our house. It was as if the fish and turtles and gators were mimicking children who exhale in just the right way to see their breaths on a cold day.
With the sun rising on the eastern horizon behind the pond and the icy grass crunching beneath my feet, I had one of those moments where I marvel at God's awesome artistic hand.

EJBFactory

A handy utility/helper class for obtaining instances of EJBs (and InitialContext instances and Home interface instances)

In a recent mailing list discussion I mentioned a utility class called EJBFactory that I've used in the past. It encapsulates most of the ugly boilerplate and error-handling code that an EJB client usually must include in order to obtain references to EJBs. I offered to publish a version of the code, so here it is:
http://www.rizzoweb.com/java/EJBFactory.java

It is not complete; for one thing, as the class comment says, it does not do narrow() ing of the remote references it gets. But that should be easy enough to add, and the more robust, complete version of this idea is in code owned by a previous employer of mine.
Hopefully someone will find this interesting and useful as a starting point for implementing whatever their EJB client code needs. I welcome any feedback about improving it.

Private Abuse

The use of private scope qualifier for methods is one of the biggest barriers to reuse in Java.

I was recently searching for a way to dynamically get an instance of a java.lang.Class that represents a primitive type (basically, I needed a dynamic form of what you get when you reference something like java.lang.Boolean.TYPE). I never did find an acceptable way to do it (please email me if you know of one), but someone brought to my attention that there is a method, java.lang.Class.getPrimitiveClass(String) that appears to do exactly what I need. Great! No - the method is private, so I have no chance of ever using it.
This gets to one of my biggest peeves about the state of the Java programming art - the abuse of private, which I see as one of the biggest hurdles to reuse and extension.

A typical response to this position is that "private has a definite use and can often times be preferred as once you make something public then so it must remain for ever," but I take issue with those points.

First of all, they're forgetting about protected scope, which is much more friendly than private and provides the same level of "protection" (the notion of protection in coding is a tricky concept , as I'll get to later) in most cases.
Beyond that, I don't buy the argument about once something is public you can't change it. Very few of us are writing the kinds of code that is set in stone - refactoring is usually an option. Deprecation is your friend, too.
Actually, if you are writing some kind of code that must be set in stone, all the more reason to use protected instead of private. Because in that kind of situation (rare as it may be) you should be striving for more flexibility, not less. Private scope can only add flexibility for code in the same class; on the other hand, for increased flexibility of all other code (the clients/callers and extenders), protected and public provide much more flexibility. When you use private, you are essentially assuming that you know exactly every way in which the code might be used or extended, which is, IMO, rather short-sighted and brash.

The kind of attitude that thinks that way (must make things private because I might want to change them one day or because I know this would never be needed outside of this class) is what Martin Fowler refers to as a Directing attitude (as opposed to Enabling) and I find Directing attitude to usually be counter-productive an frustrating to work with.

Finally, I'll say this: making methods private is often justified by saying "this is implementation specific and could 'break' the code if used externally." But again I find that a bogus argument - if I subclass a class and call or override its protected methods and it does not behave how I thought (so long as it adheres to the documentation or other contract), it is not necessarily the original class author's fault. I would certainly expect testing to happen, which would uncover any false assumptions or mis-use of inherited code. Again, Directing vs. Enabling - I prefer that I'm given as many tools as possible rather than being stuck with the limited set that
some original programmer thought I would need.

OK, one more "finally": Smalltalk, probably the most pure of widespread OO languages, gets by just fine without private methods at all. I've never heard of anyone coming upon a situation where they just NEEDED them and where marking them as "intended to be" private
didn't suffice. Here is an excellent article on the subject
If you read nothing else I've written in this diatribe, read at least that and the Martin Fowler article. They are written by far more effective writers than I, and it shows.

Sorry for ranting - it's late and I was bored. Seriously, I've spent 10+ years thinking about this topic on and off, and my position is very firmly set after all that time.

Code Structure: Multiple Exit Points & Code Standards

On the StriaghtTalking-Java list today, the following question came up:

"What is the consensus with regards to single entry, single exit methods. I was never taught to code to this convention but recently heard that some companies require it. I wondered how people felt about this?"

There were many responses, some agreeing but mostly disagreeing that it was a good "standard" to enforce. Some of the arguments in favor of single-exit-point-ness were:

• Multiple exit points can lead to more bugs
• There's too much license in "sometimes it's ok to do x". That's the same as saying "It's always OK if I feel like it on any given day."
• It is easier to "see" the method structure with one exit point.

My two cents is that code readability wins out over dogma or "standards adherence." Sometimes a single exit point is the most clear structure and makes the code clean. However, I've read and written many, many, many methods that were far more readable with multiple exit points that they were with only one. I also agree that small-grained methods make this even less of an issue, and that exceptions usually throw single-exit off anyway.

To address the "more potential for bugs" argument, I respond with unit testing. A method that is complex or intricate enough to have multiple paths of logic should usually have a set of tests for each of those paths.

In summary: sometimes a single exit point (return) is more elegant, but sometimes multiple returns lead to more elegant code. We might all disagree (and almost certainly do) about how big those two "sometimes" are in relation to each other, but the bottom line is, "Readability/elegance/simplicity trump all coding rules or standards" - it's going to be pretty hard to argue with that.

In general I feel that code standards usually go too far, are too dogmatic. A coding standards doc should, IMO, always be called a "guidelines" doc and the first section/chapter should state something like "code readability and elegance" trump other rules. Yes, it requires careful attention and discipline to avoid the "I don't feel like it today" trap - but if programmers don't have discipline good attention to detail, well then "where they put their curly-braces" or "how many exit points they have in methods" are going to be the least of the problems...

Java Generics: I'm not alone

My thoughts on the addition of parameterized types (aka, "generics") to Java have been documented well here, on the StraightTalking-Java mailing list, and the Eclipse newsgroups. Bruce Eckel has always been on the same side as I, but until now there was little high-profile support for that position. Now, however, it appears to be gaining momentum. Ken Arnold has posted a blog entry "Generics Considered Harmful" and I'm glad to see it got Bruce Eckel's attention as well as Lambda the Ultimate.
Mr. Arnold and Mr Eckel are more eloquent than I have been about expressing the position that we all seem to share - I particularly like Ken's coining of the term "complexity budget." That is the succinct, easy-to-understand phrase that I have been searching for in my ramblings on the topic.
Bottom line: I'm glad to see some others coming out to express the idea that this "upgrade" may have pushed Java out of the realm of "simple" languages for good. I'm not alone any longer in my distaste for the increasing complexity the language designers are introducing.
Not that the company makes the discomfort any easier to live with...

Early Thoughts on Portals/Portlets

I am in the process of evaluating/learning portal and portlet technology for my company. We are a HUGE organization, so there have been several efforts of exploration in various groups within the company. In fact, the "official" company-wide web-app and services framework team has actually implemented portlet functionality into the proprietary framework. I don't like the level to which they have abstracted away everything, though, so I'm making it part of my effort to evaluate their implementation. We use WebSphere Portal Server (we are a huge IBM shop, so it was the only realistic choice).

Thus far, my impressions of Java portal/portlet technology is that it is over-hyped. How many applications really have Yahoo-like requirements? Also, the portlet spec is over 18 months old at this point, but there is no public information about any activity on it. IOW, it appears to be stalled at the 1.0 level, and that 1.0 spec is quite immature. There are several key ideas that the vendors have all solved in proprietary ways that need to be part of the standard API and spec. The authors of the spec are remarkably silent on the progress of a 1.1 or 2.0 version - my educated speculation is that there is little or no progress happening at all.

The user activity I keep seeing (a Yahoo Group, articles, blog entries, etc) seems to be inordinately focused in the offshore population. I wonder if the offshore/outsourcing companies are hearing the hype from management types and trying to find ways to inject portal/portlet into every project they contract now...

Performance also appears to be a major issue. The extra processing required for every single user request is multiple times that for servlet apps, and, especially within our company, that results in apps that can handle significantly fewer concurrent users per unit of hardware than equivalent servlet/JSP apps. IBM claims that latest versions of WPS are significantly better than previous versions, but also seems to acknowledge that it is not equivalent to plain-old servlets and may never be - the stated hardware requirements for running Portal Server are pretty high-end.

Something else: I haven't seen much talk about portal in terms of transactional applications. I can see that having a "main" app as a portlet surrounded by little helper stuff like calculators, mail checkers, stock quotes, etc. would be "nice to have" candy, I haven't seen any examples of highly transactional portlets all coexisting and sharing window space.
Another potential problem is that of screen real estate - you UI designers have a significantly harder job when you're dealing with multiple portlets on every page; it means none of the portlets have as much real estate to work with as they would if they were individual pages or traditional web apps.

I think the portal idea can be very useful for certain applications that have specific requirements about incorporating multiple data views onto one page. I just don't think many applications actually have such needs. When they do, implementing it in plain servlets and JSP can be done, but would require building something like the portlet API and container anyway. It's just that I prefer to build something like that as-needed and specific to what you really need, rather than relying on a huge, bloated, wants-to-do-everything implementation like is provided by IBM, BEA, etc.

As I said, I am still learning and evaluating and planning some PoC mini-projects to explore these topics. Thus, my opinions are young and likely to change at least a little over the next few months

The price We've Paid

A few days ago I came across yet another example of why the implementation of parameterized types (sometimtes called "generics") in Java 5 (JDK 1.5) is going to hurt more than it helps. I dread the intricacy, complexity, and sinuosity that quickly results once you've started down this path...
Let me be clear, lest I get a flurry of emails from people who don't get my point: I am not arguing that parameterized types are without merit or use - of course every feature has a place where it will prove valuable. However, it is important to evaluate the cost of a feature when considering it. In the case of parameterized types in Java, the cost is an inordinate increase in syntax and complexitiy and mental overhead. The cost, IMNSHO, is very high - way too high to justify the feature.

Do we really want to have to write (or worse, read/maintain) this kind of code on a daily basis?
-------- Original Message --------
Subject: Re: (De)serialization and Type Safety?
Date: Fri, 25 Mar 2005 07:05:48 +0100
From: Philippe Marschall <xxxxxxx>
Organization: EclipseCorner
Newsgroups: eclipse.platform

What to do? Are these all ignorable warnings, given that I know I'm > putting a Map<String, List<String>> in at the other end? Even if so, I'd > still like to be able to write warning-free code Well it depends what you want, if you want type safety and get rid of the warning, something like this might work.

public Map<String, List<String>> readFromSteam(InputStream is)
        throws IOException, ClassNotFoundException {
    ObjectInputStream ois = new ObjectInputStream(is);
    Map<?, ?> currentLists = (Map<?, ?>) ois.readObject();
    return this.copyToNewMap(currentLists);
}

private Map<String, List<String>> copyToNewMap(Map<?, ?> oldLists) {
    Map<String, List<String>> newLists = new HashMap<String,
    List<String>>();
    for (Entry<?, ?> each : oldLists.entrySet()) {
        String key = (String) each.getKey();
        List<?> oldList = (List<?>) each.getValue();
        List<String> value = this.copyToNewList(oldList);
        newLists.put(key, value);
    }
    return newLists;
}

private List<String> copyToNewList(List<?> oldList) {
    List<String> newList = new LinkedList<String>();
    for (Object each : oldList) {
        newList.add((String) each);
    }
    return newList;
}

Struts: At what point does it pay off?

The topic of Struts recently came up on the ST-Java mailing list and my thoughts about it got rather lengthy, so I thought they'd be better served here than just in a Yahoo message.
The following question was posed:

I admit I don't know much about Struts, but I am wondering whether it's a bit "heavy weight" (for lack of a better word) for a small system (i.e., in terms of how rapidly you can do development in it) and/or whether there's a big learning curve involved in coming up to speed with it. Got any thoughts or experience you can relate that might alleviate those concerns?

It's hard for me to be completely unbiased in answering that, because I am already intimate with Struts. But, I'll try...

There is definitely a "tipping point" below which you may not want to invest the time into Struts. Like so many other things in our chosen art, where exactly that point lies depends in large part on the person/people doing the work and the nature of the relationship you/they have with the Goal Donors and Gold Owners ^(tm).

I would say that the point where learning and using Struts becomes worth it is likely lower than some people think/say it is. It is not as heavy as I've seen/heard some people say. And for apps with simple needs, it is simpler to use than for apps that have complex needs. IOW, in some ways simpler apps don't need as much design, maintainability, cleanliness, etc (ie, the things Struts brings you to); however, in other ways simpler apps mean less need for the more advanced Struts stuff that makes learning/using it more burdensome. Does that make sense, because it's Friday and I've had one of those weeks...?

Bottom line, if you need a small app that is low-volume, only a few pages, and pretty much will never need sophisticated logic (besides, for example providing CRUD for a simple data model), well then Struts can be too much. But I see it like buying some big-ticket power tool for your garage or shed: yes it is difficult to justify the cost and storage required to get one just to cut a few 2x4s for that small project. But once you've made the investment to have one, you can use it again and again for both small projects and large ones that come up. And the small ones become trivial and the large ones become a lot easier.

When I said "I will never do a web app with plain old servlets+JSP," I should have made it clear where my "tipping point" is - perhaps 5 pages with simple DB calls and no "business logic." Because, yes, even I wouldn't use it to, for example, make a utility app that does soemthing small like store my contacts list in a DB and give web access to them. I least I don't think I would...you know, now that I think about it, I probably would, because with Struts and its rich set of taglibs I can crank out a couple of JSPs and Action classes that do that kind of thing just as easily as if I tried to use straight servlets and/or JSP and scriptlet - And since scriptlet makes me want to throw up, I'd choose the Struts/taglibs approach if for no other reason than to hold my lunch :-)

I recently introduced Struts to the team I work on for use on a new project (re-write of an existing atrocious web app). The 3-4 people I'm working with on the project, none of them had any experience at all with Struts, although they each had worked on J2EE-based web apps. With my past experience to guide us, we have been able to get up and running in a pretty good amount of time, and that includes adopting Tiles (which I had not used before) and the latest Struts version (1.2.x - I had only used 1.0 before). Everyone, including the page design/HTML "guy" were able to pick it up pretty readily, with me providing abbreviated insight that is proably more efficient than having to scour all the documentation and mailing lists. It has gone very well so far, and now we can cank out new functionality with realitve ease.
The moral of that story is that having someone along for the ride who has done Struts before is probably a big advantage. I am not claiming to be anything special as a mentor or guide or teacher - it's just that having past experience, on the team, close at hand, made a noticable difference. My teammates have said that repeatedly over the past 4-6 weeks.

Of course, I am a "framework" guy - I enjoy using well-desinged ones, I enjoy trying to extract them from my own work - so I'm probably naturally inclined towards things like Struts that are nicely abstract and pluggable. But I'll tell you, in the past year I've also had to work on a plain servlets+JSP (with lots of scriptlet - YUCK!) application, and I was neither as happy nor as productive as I am on this new one where Struts is the Path of the Beam.

Eric

Designing with Exceptions

Rob Diana recently wrote about Exceptions and APIs, some thoughts stemming from a thread on Test Driven Development he read. On the StraightTalking-Java mailing list this spawned a lengthy discussion about the usage of exceptions, when they should be internally handled vs. thrown (possibly wrapped). My thoughts on the subject are a bit more general, but still worth mentioning (especialy since I'm trying to utilize this blog on a more consistent basis, and this seemed like a good way to start - again...)

Any object or set of cohesive objects (in some cases, an API) should only throw exceptions that are at the same level of abstraction as the interface to the object(s)/API.
IOW, the abstraction level of the object's interface must be consistent - that is not negotiable - and the thrown exceptions are part of the interface. Thus, the exceptions must match the abstraction of the rest of the interface (parameter types, return types, etc.)

If we follow this rule (it is more than a guideline, IMO) the decision about what kinds of exceptions to throw becomes easy in 99% cases. An app's persistence layer does not throw JDBC errors or hibernate errors, because those are implementation details of that layer - it is written at a "higher" level of abstraction. However, it can reasonably trap those kinds of errors and perform whatever reasonable action the developer chooses (which might include, for example, retrying the operation an extra time), most of the time wrapping the underlying error and throwing some exception that matches it's interface.
Same for a "business logic" layer - it talks in terms like CustomerAccount, Product, BillingCycle - so it can also use notions like CustomerNotFoundException, ProductDiscontinuedException, and BillingCyclePassedException (if the designer so chooses). It would not, however, use notions like SQLException, IOException, EJBException, etc. Those are implementation details - you would not want to change your whole interface just because the implementation changed from using straight JDBC to something else, for example.

I'm surprised there would be any debate about this. APIs (or any objects/set of cohesive objects) are certainly capable of handling some kinds of errors internally, but many times the context of the call is best able to know what to do.

Greece Trip Photos

OK, most everyone knows, but for those of you who don't:
We've finally got all the pictures from our trip (all 230+ of them!) organized and posted on our web site. The page is http://www.rizzoweb.com/photos/Greece2004/
Enjoy, and let us know if you'd like copies of any of them.

Eric & Jazmine

Ia - Another slice of heaven

When we were on our way to Santorini island we were unsure of which town we wanted to stay in, and for how long (we have been considering visiting another island for a couple of days). Well, Ia and the Filotera hotel have made the decision easy! Ia is a charming old-world style town built right into the cliffs, where all those famous pictures of little cubical white and blue houses and blue-domed churches come from.
Today we spent in an easy stroll through the town, Jazmine visiting every little craft shop and souvenir stand (Jazmine: "Not every one; every other one maybe...") and Eric taking about 1000 pictures.
We met so many friendly people - shop keepers, artists, other tourists - that we can't even remember them all. But most enjoyable of all were the quite, traditional atmosphere and the picturesque scenes that we discovered all day long.
Here and here are some of the dozens of such scenes that we captured.

Our afternoon ended at the cliff-side northernmost point where hoards of people gather for the sunset.