At Michael Lucas-Smith's request, the TypeLess plugin for BottomFeeder has been renamed - to BottomFeeder-TypeLess-Plugin. There's a new one as well - a Telnet client. It also looks like some dev time tools are being built into TypeLess - the VW internet console projects - BottomFeeder, TypeLess, ane Pongo - are picking up a head of steam!
Always a challenge when you go to a child's birthday party - how many toys will get lost (one so far, down the sink), how many fits will be pitched (one major one so far). Most of the kids left, and we can all settle down for some pizza...
Uche Ogbuji has doubts about the value of SOAP:
Jonathan Bartlett has a spot-on rant on why CORBA is still superior to SOAP. I think a lot of people know this, but fear to say it. Duncan Grisby, the lead developerof the superlative omniORB came to the tenth International Python Conference (IPC10) and was on a Web services panel. I think he came expecting to have to defend CORBA's honor and was surprised when just about all the panelists agreed with him that CORBA is better than SOAP in practice.
He wasn't done there; he posted later on SOAP vs. CORBA:
This is a more in-depth comparison of SOAP to CORBA than the rant I blogged earlier. It is quite sharply biased against SOAP (I've never been much swayed by "eeew XML is so verbose" arguments). But I think many of its points are fundamentally sound. Mike Olson also ran some SOAP/XML-RPC/CORBA performance tests on Python, with remarkable results.
Those benchmarks came out with SOAP being dramatically slower than CORBA. Not a big surprise; sending reams of uncompressed text over the wire - as opposed to a binary protocol - isn't going to be fast. But he wasn't done yet - read here as well:
Rem acu tetugit Paul Prescod. IOW, He nailed the point, as he so often does. I think the idea of merging header and body into a single document is the single biggest flaw in SOAP. Yes, SOAP section 5 (the RPC datatyping section) was probably the largest overall mistake in SOAP's evoution (as even heavyweight SOAP boosters have started admitting now), but it is far less fundamenal than SOAP's monolithic design.
We (Cincom Smalltalk) support SOAP well; it's got a bandwagon of support, and there's no way we can just tell developers to use CORBA instead. Still, Uche makes some very good points here - well worth considering if your technical options have not been closed off ahead of time....
I'm feeling pretty confident about the BottomFeeder code at this point - I think 2.8 is pretty much done. All I am waiting for now is the gold CD for VW 7.1 - when that happens, BottomFeeder 2.8 will be released
I've noticed that you can subscribe to Feedster queries as RSS Feeds. For instance, this query will produce all the BottomFeeder references found - as an RSS feed.
That has possibilities.
So much for a nice meal - my wife's car had a flat, so I got to spend quality time with the jack. Joy. The meeting went pretty well - the customer I was meeting with looks like they will be expanding their use of VisualWorks. Always a good sign when the decision makers stay in the meeting, and the meeting goes for 90 minutes. So now I'm catching up on the day's mail and feeds...
I am off visiting a customer in Washington, DC this afternoon. I'll have more to post later
After a power outage a few days ago, I forgot to restart the application that generates the feed. Dohhhh!
Spotted in comp.lang.smalltalk:
We're planning on going to Java because it seems to have a larger community right now and because we just don't have anyone left that can program in Smalltalk.Before committing youself to this plan, I recommmend sizing Dome (I'm sure Reinout or Bruce could give you rounded figures on no. of classes, no. of methods, and no. of statement and cascade lines, if you are not set up to get them yourself). Then compute how long the Java rewrite will take you by assuming only a sane number of lines of code per day written by whoever does it. Check this by getting a rough estimate of how many years of effort wrote it in the first place (find someone who was on the project, ask them how long and average team size, thence fudge up a guestimate), then multiply by three (it's slower to program in Java) and divide by your 'porting is easier than writing' fudge factor.
The above should take you very little time (there's no point in getting very accurate numbers as software metrics is a very imprecise science). If the two figures that result are
- within even very rough hailing distance of each other
- both way over any realistic budget the rewrite could ever have
then I recommend you stop even thinking about it (and, even more important, stop even talking about it as it will just block more sensible solutions). Instead, devote your limited budget to specifying what changes you want and posting them on Dome's pages. Invite people to convert the requirements into XP tests, agree their tests with you (good Smalltalk XP tests are very readable even by non-Smalltalkers) and thence solve them. It might happen even if you offer no money. It will happen if you offer money. It will be much cheaper than the rewrite even if the latter were feasible.
I think you should provide a parcel load of your vw7.0nc port as the first thing.
Just my 0.02p. HTH.
Yours faithfully Niall Ross
That's as good a summary on this topic as I've ever seen, and I've written about this before.
The Fuzzy Blog has a nice post on BottomFeeder's support for Feedster this morning.
I had sent Scott an email, and got back a very nice response. I had only just added this support into the 2.8 dev stream, so I went ahead and posted a 2.7 patch last night that adds this to the shipping version. Bf should pick it right up; if not, here's a download link.
People wanting performance may want to ponder the stats on this page:
Table 1. Results of the benchmarking applications
Technology Connect time Send string (21,000 characters) Receive string (22,000 characters) Send 5,000 integers Client LOC Server LOC Actual message size sending 1,000 characters Actual message size sending 100 integers Raw sockets 0.002242 0.001377 0.001359 6.740674 57 25 2,279 85,863 CORBA 0.000734 0.004601 0.002188 1.523799 37 18 2,090 27,181 XML-RPC 0.007040 0.082755 0.050199 100.337219 29 17 4,026 324,989 SOAP 0.000610 0.294198 0.279341 1,324.296742 32 10 4,705 380,288
Making the RPC mechanism human readable sure has helped. snicker.
That I have added it to BottomFeeder as a search option. Check out Feedster here
I saw this interesting post from Ted Leung's blog:
David Czarnecki states his reasons for not using a database to store blojsom's entries. Most of the reasons that he lists are quality of implementation issues in other blogs.I have a different take. The reason that I liked blosxom's filesystem based approach is that ultimately, I view my blog as a part of my personal information infrastructure. And I want to be able to take that infrastructure with me wherever I go (especially after today's Centrino launch). The biggest problem that I have with using a regular SQL database is the disconnected operation problem. The blog has to be up and running on the web all the time. But I want to be able to work on entries on an airplane or on the ferry, and I want an easy way of synchronizing the web version and my private version. I'd rather not write a database synchronization package. So at the moment, the use of the blosxom filesystem seems to be the best that I can do. But the nasty mtime sorting is really a pain.
While I never gave it this level of thought before, this is why I've not moved this blog to a database. Setting up a test environment was vastly simpler - I just ftp all the files from the server - and I can have the whole thing on my notebook as well. With my offline posting tools, being able to post to an offline version of the blog is less relevant for me now, but still possible - and it makes for nifty demos.
I posted on this earlier, but I just realized that it supports another truly cool feature: you can have the feed search returned as an RSS Feed.
So now I have this query coming back as an RSS Feed, so that I can see if anything new on Smalltalk has popped up recently.
This is truly, truly cool.
Here's an interesting post on the Fishbowl:
One of the tricky aspects of API design, especially when designing the base APIs for a programming language, is deciding what goes in, and what stays out. Think of a string. There are an enormous number of things you can do with strings, but to put all of those operations on the String class would just be impractical and bloated. So as the designer, you take those operations that you feel would be most generally beneficial, such as finding the length, searching for and extracting substrings, and so on, and leave out the rest.Some languages, such as Smalltalk, Objective-C, Ruby, Python, Perl, CLOS... Okay, a great many languages allow you to add behaviour to existing classes. So, for example, if your application really needs a method that reverses a string in-place and the language designer has decided that's not necessary for the supplied String class, you can add your method directly to the String class and be done with it.
Some languages, and this is where Java sits, don't let you do this. If you want to extend a class, you have to subclass it. And then you're stuck with whatever the superclass has made visible. And you can't do it with String anyway, because String is final. This is why most projects I work on end up having a StringUtil class, and every project ends up with a DateUtil. There are things we want to do to strings and dates all the time, but there's no way to put those things where they really belong, on the String and Date classes. Which is why having a Util class isn't a code-smell per se, it's a smell in the underlying language.
This is an area you can get into wonderfully interesting discussions on. IMNSHO, it is language smell when you can't slap code where it belongs. In VisualWorks, everyone always had their own version of CommonApplicationModel - subbed off of ApplicationModel. What that told me, as Product Manager, was that there were vast unmet needs in the current implementation.
That's what it always means
Internet News has a story making the complaint that MS' XML format in the upcoming version of Office will not be terribly interoperable:
Edwards said that Office 2003 beta's handling of the XML file format means that firms will not be able to tap the rich collaborative features of Open Office 2003 without resorting to proprietary Microsoft file formats. And to truly unlock its collaborative potential, firms will have to standardize on the Windows XP operating system (Office 2003 won't run on Windows 9x), as well as Windows 2003 Server, SharePoint Server, Exchange Server, etc. As for the file formats, he called Office 2003's XML "crippled," because it strips XML files of all presentation and formatting information when saving them in the XML file format. It does not do this when saving files in Microsoft's proprietary file formats."Although it's still early in the review process, it does look as though XP XML has been so seriously crippled as to be useless to anyone but the big content management and collaboration system providers," Edwards said. "Reports are that when saving to XML, [Office 2003] strips out the presentation and formatting information, leaving near raw content. It appears, at least from the non-enterprise systems user's perspective, that all the really cool collaborative advantages are based on saving files in the XP proprietary format. Which means that "all" the users in the collaborative effort must be on the XP platform, using XP Office, connecting through XP servers. What kind of universal connectivity and exchange is that? XP users won't even be able to collaborate equally with the 200 million Win9x users. Not unless they upgrade."
And why exactly is this a surprise? Regardless of what you think of MS vis-a-vis anti-trust - if you had the hold on the Office market that they have, what would possess you to make it easier on competing (and free) tools?
Eliot Miranda recently spoke at Stanford - a video feed of his talk is available. Check it out!
I have to give a lot of credit to Scott Johnson for his work on the Roogle RSS Search Engine. There have been a lot of comments on this tool, but this one
Here's a homework project. Go to the RSS Search engine. Now go to Google. Search for these words: "InfoPath" and "OneNote." What do you notice? I like the quality of the RSS results a LOT better
I think I understand why Google bought Pyra better now. Try doing a search for Smalltalk in both places as well - for fairly obvious reasons, I like the results better ;-)
Getting the replay tv hooked into the various a/v components was the usual holler fest - my wife and I reduced to jello before we got things working in something resembling the way we wanted. The stumbling block was audio going out of the TV. Instead of having to set the Receiver, VCR, and TV on separate inputs, we wanted to have the TV pumping audio back out from whatever it was tuned to.
This was harder than any reasonable person would want
The nicely labeled Audio out always took out whatever was coming in from the antenna/cable feed - regardless of what input it was tuned to. Arghhh! We had to shudder open the manual.
Sidebar - how is it that Sony has such brilliant folks building hardware, and then hires people with a minimal grasp of English to write the manuals? Would it be too much to ask to get an understandable manual?
Anyway, back to hell. The manual claimed that we could get what we wanted by plugging the jacks into the Audio out "var/fixed" plugs on the back of the TV. That was obvious (not).... and it didn't work, at least not right off. The "var/fixed" referred to the volume being pumped by the TV. For reasons not at all clear to me or my wife, setting it to "variable" on the TV silenced the audio output, while setting it to "fixed" gave us audio - but controllable only by the receiver's remote, and not the TV's remote. That led to some swearing. The TV and the receiver are the same frelling brand!
So this morning, I'm reading Ellen Goodman's column, since Instapundit referenced it. Now, I'm no luddite - I have a 100 Mbit house (wired) LAN, and an 11 Mbit wireless house LAN, two replays, and a number of computers on the LAN. But heck, there was a lot of common sense in that article. A lot of the electronics are getting too complex - maybe audiophiles understand it all, but I sure don't. My Living Room Receiver seems to constantly forget whether the CD input is analog or digital, and the readout on the blasted thing requires me to lie on the floor to read it!
There's a market opportunity for some vendor that makes a sharp break with current component plugs, and goes to something simpler, like a USB based interface whereby the receiver figures out what it's got plugged into it when it powers up. The current ugly proliferation of remotes and oddball cables can't be making anyone happy
I've learned at least as much this time around as the kids I've been working with. This looks like a good place to start next time around. Today, I'm going to use the EToys demo that is in Squeak, and then next week, try to come in with a new one. When I teach this class in the spring, this is the way I'm going to go about it.
According to this post, BottomFeeder is in the same ballpark as Radio, and a fair bit smaller than Syndirella. Bf weighs in at 36MB of RAM on my machine, with the contents of 100 feeds sitting in memory.
The 80 hour replay is back and set up, with the new 51" widescreen TV. We are busy configuring it now. My wife's first word's when we got it back:
"My Preciousssssss"
Here's an interesting piece that I found on Lambda the Ultimate - hat tip to Michael Lucas-Smith for pointing it out to me. Here's an interesting quote:
In my (limited) experience, nobody at a university has any clue as to what OOP really is about. In one "advanced" Java class, the professor once said that he had never been able to find a purpose for inheritance and that it would be best not to use it
Wow. And one of the stated reasons for going with Java is that the students come out of college already knowing it. Hmmm. Based on this, there's a reason for not using Java. And this is consistent with my interactions with Java people who did not start out in Smalltalk - there is very, very little understanding of OO principles. Not that inheritance can't be done badly; it quite often is, and deep inheritance trees are typically a danger sign. But look at that comment above - no discussion of pros/cons, no explanation as to why using composition is often better (see class List in VisualWorks, for instance) - just a flat No.
Take a look at this comment further down in the Lambda thread
I was about to make a snide comment along the lines of "How would you write a GUI toolkit in Java without using inheritance? Without subclassing you would need to add a hook interface for every imaginable behaviour of every component!"Then I started to remember how Swing is written :-)
Later on in the thread we find this piece of brilliance:
Inheritance is the key to separation of interface and implementation, and hence polymorphism, in a statically typed OO language. This is perhaps the primary facet which separates languages like Java from "object-based" languages like VB.Frankly, I don't know how projects of any significant size are accomplished using dynamically-typed languages, with their lack of interface inheritance
Translation: I've never worked in a dynamic language, so it can't possibly work. You have to love these people. This seems to be the pattern of learning going on in Java and C# - We know nothing about these other technologies, so they must be bad. Richard Gabriel had it about right in Worse is Better.
The more things change....
I've uploaded a new BottomFeeder parcel - the upgrade manager should pick it up. I am also pushing up an entire new build, so that anyone grabbing the gzip files should immediately have the latest stuff.
The timezone code should now work on Mac OS X, thanks to the Heeg folks.
Now that slashdot has noticed Smalltalk, maybe there's some interest. This year's Smalltalk Solutions show has a keynote by one of the Croquet developers. Come hear David Smith tell you what it's all about!
Blogs I would read a lot more often if only they pinged weblogs.com when they updated.....Without pings, they languish at the bottom of my blogroll where I won't notice or visit them. My blogroll is my only mechanism for keeping track of the blogs that I read regularly - aggregators just don't do it for me, and with tabbed browsing my blogroll is almost as efficient for staying up to date.
Personally I don't check there - I use BottomFeeder to aggregate. My peeve is the lack of a good RSS Feed. Still, I took this point to heart - my habits aren't everyone's - and updated the blog to ping weblogs.com after each update. I'll have to look at blo.gs and see about pinging it as well....
Linux Today writes on Buffer Overflows:
"Buffer overflow problems always have been associated with security vulnerabilities. In the past, lots of security breaches have occurred due to buffer overflow. This article attempts to explain what buffer overflow is, how it can be exploited and what countermeasures can be taken to avoid it."Knowledge of C or any other high level language is essential to this discussion. Basic knowledge of process memory layout is useful, but not necessary. Also, all the discussions are based on Linux running on x86 platform. The basic concepts of buffer overflow, however, are the same no matter what platform and operating system is used..."
Here's a hot tip - use a better language. Those of use using better tools (Smalltalk, anyone?) don't have this problem. So long as developers choose to create tools in primitive languages, problems like this will persist. Time to leave the sharp sticks and pointy rocks behind guys.
Croquet got noticed by slashdot this morning. The common misinterpretations are already running amok - it's slow, it's interpreted, yada yada.
Cool to see Smalltalk get noticed though.
Lots of people have been talking about this McDonalds WiFi experiement. Apparently, they are going to put in access points in a few cities, and offer an hour of free access if you buy a value meal.
I'm sure business travelers will like this; I would have loved such a thing when I was traveling more often. Still, McDonald's is not my ideal for hanging out and surfing. Starbucks seems much nicer, and has lots more power outlets. Not enough seating though. McDonalds, if they want this to work out, is going to have to install more access to power.
What I'd really like to see is places like Borders or Barnes and Noble doing this - they have comfortable seating, books, and coffee - just about perfect for this kind of niche. Unlike McDonalds - which mostly wants to shepard people in and out - those outfits are encouraging people to linger. What better way to do that than to offer WiFi?
I had someone complain about the fact that BottomFeeder always launched a new browser in Linux. I had no idea how to go about reusing an existing browser - but there were helpfule folks on the IRC channel, (thanks pete!) who lent a hand.
So now, in the latest dev build, you can launch a page from Bf and have it reuse an existing browser - so long as it's Netscape or Mozilla.
Next time someone says that Java is the answer, have them read this. Then show them your development cycle in Smalltalk.
No, I haven't finished laughing quite yet:
Interesting thread at TSS about 'edit/compile/debug/startup cycle for people on various J2EE projects'.I'm pretty much sure that any VS.Net user will laugh at us seeing all these wasted minutes and seconds on silly compile/deploy cycles. Ant and Maven are a solution to a problem: treating software development like a factory line consisting of many steps which can be automated. The problem is with all these steps and complexity of each step we end up struggling with a giant slow build process.
The solutions offered look awfully complex to this Smalltalker...
Matt Croyden spotted something interesting:
Here's the MSDN article. I'm not sure if the final version of Office 2003 will be as ugly as these screenshots, but I hope not. It looks like the Easter Bunny got in a fight with Office 2003 and Office 2003 lost.
Seems you can integrate things like Google's web services (just like I did in BottomFeeder - the picture is amusing.
Have a look here for the up to date roadmap presentation.
The .NET White Paper has been updated - mostly some wordsmithing from the marketing folks. Have a look, and send feedback to me
I've got new BottomFeeder parcels posted. The new stuff uses some code from Holger to set the TimeZone and local time at startup. It doesn't work yet on the Mac; hopefully someone with a Mac will get that working.
I had a few issues with my pingback and weblog ping code, which are now sorted out. The problem was all on my end; improper use of the XML-RPC library. An update just showed up on weblogs.com, so it looks like it works now.
Aspect Oriented programming - the approach, not a particular implementation - has been patented. Spotted on Ted Neward's blog, who in turn reported it from here.
Sigh
The Fuzzy Blog writes on vendor/consultant squeezing in the IT sector, and how it's going to hurt:
From the Wall Street Journal:Mr. Kheradpir Puts the Squeeze on Tech For clues to the tech sector's failure to revive sagging sales, pay a visit to Shaygan Kheradpir. Verizon's chief information officer relentlessly pushes his charges to get more out of less equipment, an attitude that spells gloom for tech giants.The article is excellent and a wake up call I suspect for a lot of us. This is very similar to what I wrote recently about all vendors getting squeezed in the down economy
this is not surprising to me. I've been saying that the outsourcing trend is nothing new either - it went through manufacturing like a scythe as back when I was in high school (anyone remember the movie "Mr. Mom"?)
What's new is things like outsourcing and cost cutting hitting IT. In a very real sense, it's a sign that the industry is growing up - customers are starting to hold us accountable. This also went through manufacturing - see this story on GM and GE cost cutting around suppliers.
John Lam makes some interesting observations about test-first as it relates to GUI development:
I've been spending a fair amount of time recently writing GUI rendering code. I've also been spending a fair amount of time recently grappling with unfamiliar API's. These experiences have revealed two areas where test-first development doesn't quite work:
- GUI rendering code where "correctness" is determined by how something must look
- Early stage implementation where interface churn is the norm
The first case encompasses virtually all of GUI development, regardless of whether your GUI is an HTML page or a traditional Windows application. In these cases, whether or not something is "correct" depends on how an object appears. Unfortunately, there are usually several different ways to render the object, all of which yield correct results. Furthermore, it's really hard to determine how an object is rendered programmatically, whereas it is usually quite simple for a human to determine if an object looks "correct".
Yeah, I can definitely see that. A lot of the GUI is subjective rather objective. A test can tell you conclusively whether or not a transaction happened - it can't tell you whether the foreground and background colors are frelled. Ultimately, you're going to have to do some human factors work.
Gordon Weaklien writes:
Jon Udell is right. The problem with writing for the web isn't that there are no editors, the problem is that your editors speak up only after you've stuck your foot in your mouth, as I just did when I labeled scope and polymorphism as design patterns
Yep. The Test comes first, then the lesson....
The talk went pretty well - I didn't get to meet Matt Croyden, local blogger - maybe next time. The presentation was fairly well received, and generated a good conversation - lots of good points and questions. The upshot of the conversation seemed to be that there are cultures surrounding the various programming camps, and that the culture surrounding Smalltalk encourages frequent testing - more so than the C language family. IMHO, this is due to the fact that in C , Java, C# (et. al.), you spend a fair bit of time just trying to make the compiler happy - a situation that simply does not come up in Smalltalk. All by itself, that explains a lot of the differences.
I think I got most of my points across, and had a good exchange of ideas with the group.
I handed out a few NC CD's - I should have had more. Of course, people can always follow the download links. Afterwards, we headed out to a local watering hole for some more conversation. All in all, it was a very pleasant time.
and it'll stay light until after the XpDc meeting. I'll be bringing VW NC CD's along as well. I had a bunch of errands to run this afternoon, and spent this morning pondering poorly formed XML. Some people apparently think that any old HTML tag can just be slapped right into their RSS feeds....
and it'll stay light until after the XpDc meeting. I'll be bringing VW NC CD's along as well. I had a bunch of errands to run this afternoon, and spent this morning pondering poorly formed XML. Some people apparently think that any old HTML tag can just be slapped right into their RSS feeds....
There were a few more updating issues with the new HTTP code, which I think I've addressed. In the process, I ran across some oddball XML parsing barfs; there are a handful of feeds I follow that currently have bad XML - unclosed HTML tags, invalid characters. The landscape for well formed XML isn't getting any better...
I'm uploading a new dev build. I've also slapped up the new parcels for the upgrade manager. It seems that in the transition to the new HTTP access I split out, I broke the handling of gzip decoding. That's now handled.
Just a reminder that I will be speaking at the XP DC Group tomorrow night. Follow the link for details.
Just a reminder that I will be speaking at the XP DC Group tomorrow night. Follow the link for details.
If you would like to see what's coming in the 2.8 release of BottomFeeder, then have a look at the User's Guide for 2.8.
Kudos to Rich Demers for this excellent work!
Sun wasted no time making hay from the SCO lawsuit:
"Sun is waisting no time taking advantage of the SCO lawsuit against IBM. They are making statements trying to play up Solaris as a safe harbor for worried Linux and IBM users. John Loiacono, VP of Sun's operating platforms group, "For people looking at the issues at hand, we are a safe harbor. We have absolute rights to our technology ... We're changing our strategy around Linux (but) we're pausing because we're trying to figure out what the implications of this are going to be". So, this begs the questions... What are the short term implications for the new Linux based desktop we've been hearing about from our fair weather friends? How will the SCO lawsuit affect Sun's long term strategy with Linux and Open Source?"
So how does this all play out? The smart thinking seems to be that SCO wants to be bought. In the meantime, it could make for some entertaining industry watching from the cheap seats....
This looks interesting - an RSS search engine, playfully called Roogle. It's only just been put up, but it's an early sign of what Google will likely do with their purchase of Pyra
After this post, I had it pointed out to me that mailto: links in BottomFeeder (and Twoflower) did not work. They do now. On Windows, the mail tool associated with mailto: links will be spun up. On other platforms, a mail window will open, allowing the user to send mail to the recipient specified in the link.
This is an interesting post. apparently, the way Java installs, the JVM optimized for client usage (rather than server) is the default:
Amazing, then, isn't it, that most default installations of Java-based (as opposed to native-code implementations) J2EE containers don't make use of the VM tuned specifically for long-running server operations?...
To fix this, if you can get at the command-line used to invoke the JVM, add the "-server" option into the command line parameters. If this is somehow hidden away from you, simply rearrange the options found in the jvm.cfg file in the JDK to list the "server" option first. Bear in mind, however, the comment at the top of the jvm.cfg file: this file format is subject to change and may use a different mechanism sometime in the future. (Case in point: the JDK 1.3 mechanism didn't make use of the keywords following each entry-KNOWN, ALIAS, and so forth.) Future J2SDK releases may change this mechanism, so be prepared to do a little spelunking when J2SDK 1.5 is released.
Now sure, it's easy enough to deploy VW servers badly - deploy an image without mucking about in MemoryPolicy and ObjectMemory, and you'll eventually get bitten. I guess what I'm curious about is, how many people even know about these sorts of server tuning, without regard to development tools?
I've posted a new screen shot of BottomFeeder. It occurred to me that the old shot was getting long in the tooth....
We have a draft white paper out on Cincom Smalltalk and Microsoft's .NET platform. Jave a look, and send feedback to me.
So some folks in Java land are figuring out that versioning issues might require shipping a custom runtime:
Ted has a post detailing how to use a private JRE install for a java based app to side step versioning issues. This is great stuff, I used Ted's earlier white paper on the subject to do a private JVM on a current project. If you're a Java guy you need to be reading Ted's blog.
While I understand what the motivation is, doesn't this minimize the "it's standard, it's everywhere!" argument for Java? I can build faster in Smalltalk, and ship a custom runtime (smaller as well). So where's the advantage?
After the refactoring I did, testing continued to show regressions here and there. Not a big surprise. I think I've got all of them fixed though; testing hasn't turned up any new problems.
The bottom line is, I think the 2.8 BottomFeeder release looks good for synching up with the VW 7.1 release. When VW goes gold, I'll package a new image, and push Bf. The objective now is to not have to do a new base image build after that until VW 7.2 ships.
|
| Subscribe to WebVelocity |
| Visit this group |
