Viewing posts by mhughes
I've been playing around with a few things in ObjectHandles today. The first is multiple-selection. Last week Vlad Janvarev sent me a patch that got it working for non-rotated objects. I put that in, and spent most of my day today figuring out how to extend it to rotated objects as well (dealing with 3 coordinate spaces at once makes my head hurt!). To try it, press the shift key and select multiple objects on the screen, then you can move, rotate or resize them as a whole.
[kml_flashembed fversion="10.0.0" movie="http://rogue-development.com/uploads/ohv2/ObjectHandles2Example.swf" targetclass="flashmovie" publishmethod="static" width="720" height="600" fvars="undefined"]
View-Source is enabled in it.
It's not working 100%, and I'm not sure why. If anyone has any ideas, let me know. The broken part is if you rotate 2 objects, then select them both, then resize them really small. At some point they sometimes start getting bigger instead of smaller depending on the rotation. I'm baffled.
The second thing I played with is the idea of "Decorators" that can draw interesting info based on the state of the set of objects either being moved or currently selected. There's a quick screenshot of a sample one I did below.
This is also in the link above under "Example 8". This is just a proof of concept for now. If you want to try it, do it before trying the multi-select since the multi-select can leave objects on fractional pixel boundries which won't line up perfectly.
Neither of these is ready for prime-time yet. The multi-select stuff is creating tons and tons of temporary objects so the GC kicks in periodically freezing the interface. That'll need a little optimization.
For the ObjectHandles fans out there, I've just submitted changes that let ObjectHandles 2 play nicely with FlashBuilder4 / Flex 4 SDK. While doing that I fixed a couple bugs, and set up a build environment so I can easily publish OH2 releases onto the google code page. So now you can download OH2 from the downloads section of the google code page. (Previously, you could only get it from subversion) That package contains source, documentation, and precompiled swcs for both Flex 3 and Flex 4. http://code.google.com/p/flex-object-handles/downloads/list
I hope to write some better documentation on how to use this new release soon. If you've been using ObjectHandles Version 1, it's not a straightforward port to the new stuff. There are drastic changes to how it all works.
Today, I've been experimenting with project structure and workflows. I've got two major problems I want to solve.
When working in Flex Builder, if you have a lot of non-embedded assets, it can go really slow. At seemingly random times Eclipse will decide it needs to delete all of your output files and re-copy them. For our current project, that can take 10 minutes. We have yet to figure out what triggers this behavior.
When working in Flex builder, if you have a lot of embedded assets, it can go really slow. Especially on clean builds, or builds that touch a lot of modules. This is an every-compile type thing, but is far less severe than problem #1.
Solution for Problem #1
Don't let Eclipse do the copying for you. Put your assets outside of your source tree, and turn off "Copy non-embedded assets". To the right is an example directory structure. There are a few differences than most Flex/Flash builder projects.
<?xml version="1.0" encoding="utf-8"?> <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768"Since the embed is relative to the source folder, we need to use paths in the form of ../assets/art/
<s:layout> <s:VerticalLayout /> </s:layout> <mx:Image source="@Embed('../assets/art/Image1.png')" /> <mx:Image source="../art/Image2.png" /> </s:Application>
The runtime loaded assets are relative to the final compiled location, so those take the form ../art/
Now, eclipse will never try to manage your assets. This appears to completely solve problem #1.
Solution for Problem #2
A while back I blogged about turning a Flash Catalyst project into a .swc. (Read that here)
I dusted off my script and tried it with the Beta-2 of Flash Builder and Catalyst. And low-and-behold it worked without any changes. The only thing I had to do was reset my FLEX_HOME environment variable to the new location.
So, if we were to move away from a model where we embed assets from designers into Flash Builder, and to a model where the Designer puts those assets into Catalyst, and then we run a script to compile the catalyst project into a .swc, I think that would completely solve problem #2.
So it's been a week since I got my Verizon Droid. How's it been?
I had been using one of the G1 phones on TMobile's network. It was running Android 1.6, the new Droid is running Android 2.0. Let's compare Droid to that first.
Let me start by saying, they're not all that dissimilar. The one plus the G1 had was the keyboard was easier to use. It actually had separate physical buttons whereas the Droid has them all on a single etched piece of rubbery plastic. The droid is faster, has more memory and storage, and looks better - all by a lot. Holding the phone if feels like it's engineered and manufactured well. Holding the G1, it kind of felt like a toy.
I haven't had any problems finding or running any apps. All the ones I've tried have been great.
The new Google Maps with navigation is amazing. Better than my Garmin stand alone GPS unit. It's got "layers" now that can overlay all kinds of things. Some of my favorites include traffic and Wikipedia. The Wikipedia layer shows all of the Wikipedia references on a map. When looking around my home, there's maybe a dozen points listed. I'm hoping a Geocaching app takes advantage of that layer functionality soon.
The battery life seems good. I used the navigation app for an hour and a half on my commute to work one day. That includes the screen being on the entier time, GPS updates contantly, and lots of network traffic. As well as the speaker telling me the directions and a traffic overlay showing me where the road would slow down. At work, I left all of the services (bluetooth, wifi, gps) all day long. I consciously tried to use it as much as possible. At the end of the day there was still 15% battery life left. Normally, I plug it in while driving, but it's nice to know I dont have to.
So, if those things were the only differences from my old phone to this one, the $200 TMobile cancellation penalty, plus the $200 new phone cost might not have been worth it. But there was one major other difference. The network. Verizon is amazing compared to TMobile. I've used the same speed-testing app on both phones in a variety of situations. The fastest speed I ever saw with TMobile was around 300kbs. When I was at my house, it never went over 5kbs, usually in the 1-2 range. With Verizon, the slowest I've seen is around 300kbs. At my house, I average 500kbs. That over a 25000% increase. When in the office at work, it wasn't worth even trying to get a data signal with TMobile. With verizon, it works perfectly. This is the biggest single selling point of the entire experience for me and I'm am a very happy customer. This speed changed the way I use my phone from the G1 tot he Droid as much as the G1 changed the way I use a phone from a dumb-phone to a smart phone.
Cost-wise the monthly plans between TMobile and Verizon are about the same. I do get a 17% discount because my company has a contract with Verizon so your price may varry.
I heard a great Droid radio ad today. This one below is similar, but the Radio one was better.
Scheduling meetings through outlook might be one of the worst practices I need to deal with on a daily basis. It saves us a ton of time in the meeting-planning department but has huge drawbacks.
Problem number one, it's WAY too easy to schedule a meeting with someone. Since the bar is lower, more meetings happen. Since there's more meetings, they're often individually less valuable. Since they're less valuable people don't treat them with the respect they deserve. Nobody prepares beforehand. Meeting agendas are the exception, not the rule.
Secondly, it's not an efficient way to schedule a meeting. Wait, let me revise that slightly. It's not an efficient way to schedule a set of meetings. The normal process that is often used is to put everyone on an invitation. Find a block of time everyone is available. Book it. Later, that process is repeated for the next meeting. Even later it's repeated again. Since different people go to different meetings, individual schedules get "fragmented". Back in the days of personal assistants (or back then I guess the term was "secretaries"), they would handle the process of defragmenting schedules to make them make more sense. This leads to situations when individuals have an hour meeting, an hour to work, an hour meeting, an hour to work, etc. Without bigger blocks of time to work it's impossible to tackle certain problems. Even worse, a high priority meeting might get pushed back because other meetings were scheduled earlier.
Combine those two problems, and it actually gets hard to book a meeting. Since there are a lot of them. And since there is fragmentation in people's schedules, finding an open block that everyone can join can be really hard to do. This means scheduling happens further and further out. If you need to talk about something with 10 people and the only time slot to get them all in a room is a week away, that sucks.
A side-effect of this is that when you receive a meeting request, you often really feel obligated to accept it. Especially if the sender knows you have a free block of time. That means you're not asking yourself "Is me attending this meeting the best way for me to spend my time to advance/improve/help the organization?" I think we should be asking that question all the time!
How to define an ideal solution?
If we're going to explore other options, it'd be helpful to have some evaluation criteria. Here's what I would look for in a meeting scheduling system (in my order of priority).
So what's one solution?
First, here's a technical solution.
The first problem of meetings being too easy to schedule is tough. It really requires training people to act differently. Without designing a technical solution that somehow discourages meetings, I'm not sure what to do about that.
The second problem could have a technical solution. Imagine a "smart" scheduling system. You need to schedule a meeting? Submit the details of the meeting to some computer system. Tell it
Then the system is free to schedule that meeting whenever is "best" by some smart criteria. It tries to maximize individual people's free time blocks. It tries to schedule more important meetings sooner. It moves existing meetings when new ones are scheduled so there's always an optimal solution planned.
The downside? Meetings move. It's hard to plan ahead. Someone needs to develop a complex scheduling system. The time that meetings happen becomes "voodoo magic" to some people. It's possible to game the system. It's not flexible.
Now, here's an organizational solution that I want to try out here at TSP.
1) Meetings that HAVE to happen at a certain date/time are scheduled as normal. Got outsiders coming in? Meeting to watch the pat's game? Go ahead and schedule those as before through outlook. Hopefully that's the minority of meetings for you. (If you're the guy meeting with outside clients all day long, you're pretty much screwed any way you look at it.) A certain class of exceptional or emergency-meeting falls in here too.
2) Got a meeting that doesn't HAVE to happen at a certain date/time? You're not allowed to just schedule that through outlook. Instead, at your daily scrum we schedule those as a group. With one more constraint. You only schedule meetings for tomorrow. It's either important enough to schedule for tomorrow, or it isn't. That's a much easier, concrete decision to make than scheduling a meeting next-week. Some meetings lower on the priority list might not fit. That's fine, try to get them on the list again tomorrow.
To actually create this schedule, you're likely looking at outlook as a group.
Side-Note: I heard a rumor that Warren Buffet only schedules meetings a day in advance. I have no idea if if is true or not. But that's where I got the idea from.
Replace "Outlook" with any other "dumb" scheduling solution out there. Lotus Notes? Google Calendar? Whatever.
Don't complain that I call it outlook and not Exchange or whatever the entire-system should be called.
My solution assumes you have a short daily meeting. It would suck to have to introduce that if you don't.
There has to be better solutions to this. What do you do?