Click for more info...
Edward Tufte would be proud.
This dude will never want for work again.
- Mood:
impressed
Click either of the to visit the guy's entire page (pointed to page 2...click back to see page 1):
Also, check out his wallpaper gallery.
Your daily "creepy"
Y'know it just occurred to me that there's a fursuit performance tip that I'm not sure I've heard anybody voice yet (to be fair, I don't frequent the fursuit performance panels at cons much so this is probably a giant "Duh").
Almost every fursuit character I've seen tends to move their head in strange and twisty ways when they're trying act something out. Stuff like looking 30 degrees off the direction they're supposed to look, or twisting and craning their head around at some oblique angle like a lizard when they move.
Obviously this is merely accommodating the fact that they have very small lines of sight in these things that don't necessarily match the character's line of sight, and to get a clear view of props and the ground and stuff they have to move their head around like a lizard. Which is great if it's a lizard character, not so great if it's a wolf or mountain lion.
It makes the performance kind of stilted and odd and it obscures whatever motion they're really trying to convey when the character head's orientation sort of "orbits" the prop it's supposed to be looking directly at. Hey, I've done it too, most recently in Hudson.
I'm not saying anybody should do anything dangerous like not knowing where they're stepping, or trying to wield a chainsaw blind. But to whatever degree people can mentally "see" what they're doing by maintaining a mental map of stuff around them, and without actually twisting their head around to keep a prop in sight at all times, the better it's going to look. Or if they're panning their line of site across an area as part of the performance itself and they can make mental note of props/people/terrain they need to interact with subsequently, it's going to look much more fluid and natural.
Different people have different aptitudes for holding a 3D mental model of the stuff around them and interact with that stuff without necessarily seeing it at all times, AND to keep aware of what direction their character's head is really aimed. It's daunting enough to act out the script itself and stay synced with the sound track and other characters.
Both skills can be dramatically improved with just a little bit of practice.
Stage skits can be arranged so that the performers have reason in the script to periodically pan the scene and update their mental map.
Video performers have the luxury of doing a dozen takes to get it perfect.
David Fincher (Fight Club) often made his actors do dozens of takes of the same shot just so he could pick exactly the best one.
This head motion problem is something I've kind of noticed for a long time but never really thought about 'til I started watching a lot of fursuit performances on YouTube and on old highlights/masquerade/fnl videos.
There's probably a better word for it but I'll call it the "ILAAPBTSDOAIBIMMHTFMVRTHMCWRM" Effect, or "I'm Looking At A Prop But There's Something Disquietingly 'Off' About It Because I Move My Head To Fit My Vision Rather Than How My Character Would Really Move" Effect.
Okay that doesn't have marketing impact. How about just the Lizard Effect? Goddamn genius.
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
cargoweasel...Lovely synced video mashup to a custom drum track (more on the guy's youtube channel):
Check.
Plans to invade Earth...
Check.
One small mistake that could foil the invasion...
D:
Come join us at Anthrocon 2009!
July 2-5, Pittsburgh, PA!
http://anthrocon.org
(cross-posted to
![[info]](http://l-stat.livejournal.com/img/community.gif){kind=small}
anthrocon)
Yesterday this sign showed up taped to the wall over every toilet on the first floor (the women's room too).
Click for medium size versions:
(full size)
(full size)
It totally cracks me up to imagine a toilet full of so much horrible that a hazmat team has to send in a robot to flush it.
- Mood: amused
There's literally DOZENS of configuration XML files that are all validated against strict DTDs, are largely undocumented (Haha, XML configuration files are EASY to understand, all you have to do is read and understand the entire DTD explaining the layout! YAY! Except the semantics are totally missing so what any given thing does is a complete crapshoot). Unfortunately many of the entities you declare in one XML config file are referenced in other XML config files, and in many cases the order you import them impacts whether the server actually works or not.
So you start the server and in general the tiniest misconfiguration can completely fuck up the entire system, and other than logging "SORRY! ERROR PARSING FOO.XML", there's really not jack shit in the way of explanation of WHAT was incorrect or WHAT LINE things went wrong at. So sometimes it's "Sorry! Found something icky. Your application isn't going to run" and sometimes it's "Hey this didn't work, but I'll just log the problem and keep going and maybe you'll notice sometime later it doesn't really work."
Ultimately, it's this tangled abortion of complicated, inter-dependent shit where if you comprehensively understand all aspects of it, you can be confident you're putting out a solid, secure installation.
Now the OOP/Java nuts defend this practice as OMG BEST THING EVAR BECAUSE YOU CAN INTERFACE WITH ANYTHING AND ALL YOU HAVE TO DO IS CONFIGURE IT. They mean this in the sense that you can deploy programs to any arbitrary set of HTTP/HTTPS ports, or connect them to arbitrary JMS queues, web service connectors, databases, etc. And each one you connect it to has its own non-standard quirks and often requires different internal coding to support inside the program itself anyway. So that breaks the whole "same program" philosophy right there.
It also sucks because to deploy a complex application, you don't JUST have to know what you're doing at the Java level, but you also have to grok this hideously complicated XML-based programming language for CONFIGURING it, AND you have to be a reasonably good sysadmin. CONFIGURING is tehawesome because you don't have to PROGRAM. But when CONFIGURING becomes so monstrously complicated that even seasoned sysadmins have to spend days figuring out the tangle of details (and to upgrade from JB4 to JB5 you actually do have to make some source code changes to accommodate the way the new JMS system works), you've gone too far. The next logical step is to make the whole thing in a hideously complicated XML-based language because then it's extra super...ALL configuration NO program! Whee!
And deploying to test or production servers and upgrading them to work with new versions? Tedious and error-prone.
Because at some point CONFIGURING is just another way of PROGRAMMING, except there's extremely poor documentation, no simple tool to examine the validity of what you've set up without actually starting the server and swimming through thousands of lines of startup logs, no canonical documentation, and even then you might get it to where it seems okay, except that clustering may not actually work. And JMS queues may not actually be configured to preserve messages through a server bounce. Or any other "OMG" level ways to fuck up the installation and not really even know it for a while. It's the antithesis of unit testing.You may not notice this in development. You may not even notice it in testing. But when it gets to production and explodes all you can do is go D: .
And even if you do get that part going, then you have to bring all the ancillary services online. Which Java release is the thing designed to run on? Better get that right. How about installing MemCacheD? Actually that one is very simple, so that's not a good example. Okay, so you have to get Hibernate going. Or your DB Hiving system. Or your database. Did you configure the DB servers as dual-master with failover? Hope so!
The problem being that unlike CODE-- which has IDEs and compile time error checking and cross-referenced technical documentation and a plethora of examples how to do different things-- there's usually only very sparse documentation for CONFIGURATION files, the details and dependencies change notably from one version to the next (hey, an automated upgrader? the hell you say), and in the end it's so terrifyingly complicated that really you're actually PROGRAMMING in XML config.
This isn't even getting into the ugly tangle of competing development frameworks, each one "pissing on the problem" in its own unique way as a differentiator. A lot of them come out of Sun itself largely-- I think-- because there's thousands of engineers there ever-vigilant about the "how do I keep my job" problem amidst constant layoffs.
So they're all scrambling to build APIs and frameworks for doing stuff that is not actually heavy lifting at all. Each one adds quite a lot of complexity to the original problem. It's complexity that as far as I can tell, should not even exist.
There's a lot of libraries that are doing stuff complicated enough you don't want Joe Random Engineer trying to build it themselves. Transcoding complex media file formats? That's hard. Statistical math and analytics? Hard. Rich internet clients? Hard. Charting systems? Hard.
But let's face it, server-side web application logic is not goddamn rocket science. Serving pages is not nuclear physics. Interfacing with web services is not genetic engineering. Most of these guys build complicated horror frameworks to wrap functionality that in the end is actually pretty goddamn simple, and a lot of them appear to be doing it so they can offer seminars explaining it, write books to document it, and get consulting gigs to code with it. It's all very self-serving.
BUT! Here's the other half of the problem-- developers eat this shit up. In a world where the resume with the most acronyms always trumps the one with fewer, developers THRILL to the idea of learning the newest frameworks on their employer's dime, so they can add more acronyms and hop over to some better paying job ASAP. So they tell management, "OMG if we don't switch to the ABCFrameWork, the company is DOOOOOOOOOMED! So they rewrite all their crap in the new framework and just as it's getting solid someone says "Hey there's this new DEFFrameWork!!! Let's switch!"
And employers wind up with dev teams that are a lot more interested in adding acronyms than actually getting work done. And engineers increasingly tend to err on the side of "Complicated is better." And "Making it more OOPy is much more important than making it simple and fast." I had an OOPy type consultant take what should have been 500 lines of very simple, very fast, very maintainable procedural code that would take 1-2 weeks to write, and turn it into > 50 class files because he "didn't want to make any assumptions about how to interface with it." Assumptions I explicitly told him to make when I assigned the work. And 3 months later it wasn't even done.
Admittedly there's a lot of things you can do in Java that are nice and clean and OOPy and /probably/ more maintainable when you have less-than-rockstar coders in your organization. On the flip side, if you need real speed, there's a lot of things you can do that are quite a lot less OOPy, and to make them work you have to understand a lot more about the internals of the computer and how stuff actually works.
Case in point: An old vendor product generated invalid XML documents (ones that might have & and > and < and " characters embedded in attribute and node values). Someone wrote a totally OOPy post processor to fix them and it could process one 40K document every 1-2 seconds. The problem was we had 2 million documents to fix. I rewrote the tool using well documented but admittedly much more complex static character buffer analysis, and my version could process 2000 40k documents every second. So OOPy is awesome for structure, to a point. It's not necessarily awesome for speed.
I still believe that Java is a really great language if you're pragmatic with it. But it still takes a notable amount of software experience to know how far to take the objectiness, and a general sense of suspicion whether a given new framework or methodology really is going to make your software better in the broad picture, counting the cost of educating engineers, redevelopment, opportunity cost, and whether it really does accelerate development in the end.
And there's no canonical, trustworthy source to ask because nobody really calculates (or probably even can calculate) the total costs, they focus on the "hey this one class got 15% smaller" metric (and it might have added another 20% size to half a dozen "config" files). So the ACTUAL long-term benefit to the organization is a crap shoot, and anybody you ask-- especially your own engineers-- has an opinion rooted somewhere in self-interest.
- Mood:
annoyed
- Mood: annoyed
Google does keyword searches and that's great, but it doesn't UNDERSTAND what you're asking it.
WolframAlpha does. I can't stop playing with this thing. I am absolutely stunned. It has problems with some questions, but wow... what a beautiful start.
Here's some questions I've asked it (because for the first time I can, even if they're stupid, BUT SOMEONE CAN ACTUALLY CALCULATE THE ANSWER for me):
How much does time dilate at 0.99c?
How long do people live in japan vs finland?
Where is the international space station right now?
Show me the 4th largest country in South America based on area, population, and gdp.
What is the historical GDP of Asia?
Please factor (5x^7 + 7x^2 + 12) / (e to the power of pi).
How much vitamin A in Coke vs Pepsi?
What was the visible track of venus in the night sky in colorado springs in june 22, 1901?
Where is Pioneer 10 right now compared to Pioneer 11?
Show me the diffraction pattern for red 650nm light through an aperature of 0.2mm.
Show me all locations of the genome sequence GATTACAATTTG.
What is the mass of pi to the power of e moles of uranium?
What is the momentum of an electron at 0.9999999c?
Average salary of a teacher in 2005?
I'm doing a crossword puzzle. what words match A___ST?
Where is Echostar 1 versus Hubble?
When was the word "penis" first used?
------------------
Demonstration video
http://www.wolframalpha.com/
If this doesn't terrify every teacher that assigns quantitative homework, I'm not sure what will.
I have never been this impressed with software before. The only thing it can't tell me is the size of the chubbie I have over it.
The bulletins announce connection events and affinity group enrollments, people recommending each others' work, people traveling for their jobs, etc.
Like:
"John Smith is now connected to Bill Roberts."and
"Bill Roberts recommends colleague Jane Johnson, Director of Sales at BigCo, Inc."and
"Jane Johnson has joined 'IBM Senior Executive Alumni.'followed by
"Shrarish Chhatralamandaprahan" joined LittleCoConsulting, Inc. as Senior Vice President Of Global Operations.
LinkedIn should add a new sort of event to their system, the "$name calls bullshit on $person because $reason" event.
Like:
"Joe Blow calls bullshit on Shrarish Chhatralamandaprahan because he founded LittleCoConsulting and has never even heard of this guy.'"
Actually I see this sorta thing pretty routinely.
There's a few companies I've worked at or co-founded and people add themselves all the time to lofty executive/leadership roles at these companies, and I know beyond a doubt they did not work there.
It's often people in distant lands like Asscrackistan, but sometimes it seems to be just random people who want to fluff their resume.
Yes, we all believe that you got your Associates in Graphic Design in 2007, and you've held 3 senior executive fortune 500 jobs since then. Mmmmmhmmm.
That's why LinkedIn.com needs a "calls bullshit on" facility. *nod*
j_b...If you're a budding young writer, you know how hard it can be to come up with a compelling dénouement for your stories. Here to provide inspiration and make the job easier is the complete list of surprise twist endings to give it that extra je ne sais quoi*.
Clicky for original:
NOW GET WRITING.
--------------------
*Actually I do know what: mainstream marketability.
