Artima Developer Spotlight

Effect Choreography in Flex 4

Sorry, Readability was unable to parse this page for content.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read our FAQ page at fivefilters.org/content-only/faq.php
Five Filters featured article: "Peace Envoy" Blair Gets an Easy Ride in the Independent.

Skinning Components in Flex 4

Sorry, Readability was unable to parse this page for content.

Ten Ways to Screw Up an On-Site Interview

2009 was a bad year for me. The contract I was in ended at the end of 2008. I was not worried since I had little problem finding a programming position before. 8 months later and passed broke I finally found a job and am starting to rebuild my pride.

There were three interviews that haunt me still. They were all my fault and I can only lay frustration, desperation and ego as reasons. I really do not like interviewing either since I never seem to remember any of my skills. Embarrassing to say the least.

1) The first one was with a major bank and I was feeling pretty desperate after several month. I realized after the interview that I had all but begged for the job. I had not proven that I had any of the skills they wanted. Of course I only really learned what they wanted in the interview. All I knew before was they needed someone that knew ASP.Net and C#.

2) The next one I am not sure if I just answered badly or if it was a bad interview question. The interviewer asked me an SQL question that I did not really understand. I tried to ask him more questions and then give him an answer, but it just didn't feel good enough. Of course I knew what he was talking about later after more thought, but still.

3) The last one was, I feel, my worst. I was feeling pretty good for some reason and did not prepare. I got there early and had the charm on when I realized I knew one of the interviewers! It was a bit of a shock for some reason. Then I totally blanked on SEO and LAMP!!! I could not even remember what they were! I am pretty sure that is when the interview was cut short. I felt an inch tall. Of course I know SEO and LAMP! I have been into programming and web development since the mid 80's!

In the end, I learned many things. One was to not be arrogant. I might have over 13 years of experience, but I need to play to my strengths and not push knowledge I cannot have at my fingertips. Learning in the trenches is not the same as formal learning. I also learned again how important it is to know as much as possible before the interview about the job they are trying to fill. Then, almost the most important step, you must PREPARE. If nothing else get on some tech forums and read some other programmers thoughts on the current technologies.

*shrug* that's my experience anyway!
JD

What's New in Scala 2.8: Collections API

> From a quick first look I had, it seems the new
> collections API offers a lot of collection types, I'd dare
> say almost all widely known collection types.
>
> Without being a Scala user and only knowing the very
> basics of the language, I'd like to ask:
>
> 1) why the emphasis on immutable data structures? what are
> the benefits? aren't those slower than the mutable types?
>
The library is symmetric wrt mutability. Every major type has mutable as well as immutable implementations. Immutable ones are available directly whereas mutable ones need an explicit qualification or import.

The reason for preferring immutable is that immutable is safer. So in the spirit of avoiding premature optimizations
we made immutable the default.

Immutable collections do have persistent implementations which keep the cost overhead fairly low, and which even give an advantage over mutable for small collections (an immutable set or map of up to 4 elements takes only a single object; compare to a mutable map backed by a hashtable).

> 2) when a collection's type is a primitive, does
> autoboxing happen? for example, an Array[int] is actually
> an Array[Integer]?

For general collections, yes. But for arrays, no. Scala arrays are represented exactly the same as Java arrays. There's a section on arrays in the collections document.

The next versions of Scala will specialize further collection types iso that primitive types need not be boxed. That's an ongoing process which was started with the availability of @specialized annotation in Scala 2.8.