fluid-work IRC Logs-2011-03-15

[08:17:46 CDT(-0500)] <greggy> heidi_: I guess you did not put the paginator in online resources
[08:17:53 CDT(-0500)] <heidi_> greggy that paginator on online resources is new. i'll ping smriti when she gets in
[08:18:19 CDT(-0500)] <greggy> heidi_: k, it does not really fit there
[08:18:25 CDT(-0500)] <heidi_> yeah it's bizarre
[08:26:50 CDT(-0500)] <heidi_> greggy do you have a legit IE7? i just have IE8 with dev tools setting
[08:31:24 CDT(-0500)] <heidi_> greggy i emailed smriti about online resources, but looks like she's off sick today. see if she gets back to me, otherwise i'll dig around
[08:40:10 CDT(-0500)] <jessm> heidi_: any chance you can move education above policy and maybe also change policy to standards and policy?
[08:40:17 CDT(-0500)] <jessm> heidi_: i can't fine where to do that
[08:40:31 CDT(-0500)] <heidi_> jessm sure i'll do that now
[08:40:54 CDT(-0500)] <jessm> thx
[08:48:21 CDT(-0500)] <heidi_> oyyyy jooomlaaaaa! argh. the ordering broke. i don't know why.
[08:48:45 CDT(-0500)] <heidi_> jamon might need you to edit the database :|
[08:53:43 CDT(-0500)] <jamon> heidi_: oh? sounds like pain
[08:54:41 CDT(-0500)] <greggy> heidi_: any idea how to remove the paginator from the online resource. if not I'll dig around and try to find it
[08:55:06 CDT(-0500)] <heidi_> greggy no i don't know, let me know if you find the answer. i haven't heard back from smriti
[08:55:26 CDT(-0500)] <greggy> heidi_: she's taking the day off I think
[08:55:47 CDT(-0500)] <heidi_> jamon i clicked the "rebuild" feature or something and now a couple of the items are moving, not all.
[08:56:26 CDT(-0500)] <greggy> jessm: you working on online resources. You have a lock on the page. If not, I'll just remove the lock
[08:56:47 CDT(-0500)] <heidi_> jamon is it just me or is this really broken? http://idrc.ocad.ca/1.6/administrator/index.php?option=com_menus&amp;view=items
[08:56:58 CDT(-0500)] <jessm> greggy: sorry, i'm not, so go ahead
[08:57:11 CDT(-0500)] <greggy> jessm: k
[08:58:09 CDT(-0500)] <jamon> heidi_: not sure what i should be seeing on that page
[08:58:12 CDT(-0500)] <jamon> pidgin
[08:58:31 CDT(-0500)] <heidi_> jamon can you order anything? i have it set to show the first level, and clicked on the order sort
[08:58:42 CDT(-0500)] <heidi_> i've tried the arrows and the numbers/save icon
[08:59:17 CDT(-0500)] <heidi_> when i clicked one arrow it resorted all of the menu items into a jumble
[08:59:30 CDT(-0500)] <jamon> heidi_: i don't see anything in the menu..
[08:59:43 CDT(-0500)] <jamon> ah there, that url didn't work
[09:00:00 CDT(-0500)] <heidi_> jamon try menus->main menu
[09:00:16 CDT(-0500)] <jamon> joomla!
[09:00:27 CDT(-0500)] <jamon> heidi_: can i send you a screenshot of the order i see?
[09:00:50 CDT(-0500)] <heidi_> jamon yeah the order is wrong right now
[09:00:55 CDT(-0500)] <heidi_> i can't seem to fix it - can you?
[09:01:02 CDT(-0500)] <jamon> what should it be?
[09:01:11 CDT(-0500)] <heidi_> try just putting home at the top
[09:02:41 CDT(-0500)] <jamon> heidi_: by clicking the up arrow a lot or putting in a number?
[09:02:52 CDT(-0500)] <heidi_> jamon whatever works? neither do for me
[09:03:23 CDT(-0500)] <heidi_> i just want to make sure i'm not missing something
[09:04:32 CDT(-0500)] <jamon> heidi_: ok i have home 2nd from the top, does it affect the front page? how can i tell?
[09:04:49 CDT(-0500)] <heidi_> jamon yeah just refresh the home page
[09:05:02 CDT(-0500)] <heidi_> how did you move stuff?
[09:05:07 CDT(-0500)] <heidi_> can you get it all the way up?
[09:05:18 CDT(-0500)] <jamon> i had to click the arrow and let the page reload each time
[09:05:29 CDT(-0500)] <jamon> a little ctrl+f to find it in the menu list etc.
[09:06:03 CDT(-0500)] <heidi_> jamon do you have it showing all pages, or just level 1?
[09:06:30 CDT(-0500)] <jamon> i made all of them show up yeah
[09:06:33 CDT(-0500)] <jamon> now it is at the top
[09:06:49 CDT(-0500)] <jamon> i'm guessing changing numbers could work, let me try something heidi_
[09:07:06 CDT(-0500)] <heidi_> jamon i wonder if there's a joomla bug when you just show one level
[09:07:20 CDT(-0500)] <jamon> oh there's definitely something off
[09:07:34 CDT(-0500)] <heidi_> okay so i'm not crazy ha
[09:07:46 CDT(-0500)] <jamon> changing ordering for home from 1 to 2 puts it not alphabetically after other items with order 2
[09:08:29 CDT(-0500)] <heidi_> jamon what happens if you just show level 1?
[09:08:32 CDT(-0500)] <justin_o> colinclark, heidi_: I've pushed the additional flexible containers that gary passed along into a branch in my github repo https://github.com/jobara/infusion/blob/FLUID-4025/src/webapp/framework/fss/css/fss-layout.css
[09:08:55 CDT(-0500)] <heidi_> justin_o awesome... i'm gonna switch to fss work soon and check that stuff out
[09:09:11 CDT(-0500)] <justin_o> things that I modified were, that I made them conform to the fss class name, only used the width, and didn't add the ie hack
[09:09:14 CDT(-0500)] <justin_o> heidi_: thanks
[09:10:27 CDT(-0500)] <jamon> heidi_: now home is stuff at level 4, can't reorder it at all.
[09:10:42 CDT(-0500)] <heidi_> jamon yeah it's so wack. can we edit in the db or something?
[09:11:27 CDT(-0500)] <jamon> i will take a look at that heidi_ yeah, this is ridiculous
[09:11:53 CDT(-0500)] <jessm> heidi_: greggy: i fixed up the WBTT link on completed projects
[09:12:18 CDT(-0500)] <greggy> jessm: k
[09:12:21 CDT(-0500)] <jessm> greggy: if you take on online resources i'll take on completed projects remaining
[09:12:44 CDT(-0500)] <heidi_> jessm were those the only two left for broken link checking?
[09:13:08 CDT(-0500)] <greggy> jessm: right now I'm trying to figure out how to remove the paginator from online resources, then I'll start with links there
[09:13:37 CDT(-0500)] <jessm> heidi_: i'm not sure
[09:13:51 CDT(-0500)] <jessm> i did new and ongoing projects the other day so they're done
[09:13:59 CDT(-0500)] <jessm> once completed is done then that's all of R&D
[09:14:04 CDT(-0500)] <jessm> we should be getting quite close
[09:14:15 CDT(-0500)] <heidi_> cool.
[09:14:38 CDT(-0500)] <greggy> jessm: I did most of completed projects already
[09:14:39 CDT(-0500)] <heidi_> greggy any luck with paginator mystery?
[09:15:08 CDT(-0500)] <greggy> jessm: It must be magic :-\ I don't see it anywahere
[09:15:18 CDT(-0500)] <jessm> what?!
[09:15:24 CDT(-0500)] <jessm> why is this seeming so unstable?
[09:15:31 CDT(-0500)] <jessm> things appearing and disappearing at whim?
[09:15:34 CDT(-0500)] <jamon> greggy: me neither
[09:15:46 CDT(-0500)] <jamon> greggy: what about copying the content from the page, delete it and make a new one?
[09:16:06 CDT(-0500)] <jessm> greggy: i see the paginator at the bottom of online resources still
[09:16:21 CDT(-0500)] <greggy> the whole section has the paginator, which makes me think its acatregory thing
[09:16:42 CDT(-0500)] <greggy> jessm: yes, I'm trying to remove it
[09:16:55 CDT(-0500)] <greggy> jessm: not at all straight forward
[09:16:59 CDT(-0500)] <jessm> greggy: ah, though that's what you were saying above with "it must be magic" comment?
[09:17:34 CDT(-0500)] <heidi_> jessm did we figure out if we need to keep the 'direct links' vs just the link w/ intro?
[09:17:48 CDT(-0500)] <jessm> heidi_: on R&D?
[09:17:55 CDT(-0500)] <heidi_> yeah all the project pages
[09:17:56 CDT(-0500)] <jessm> heidi_: i say we leave it as is for now
[09:17:59 CDT(-0500)] <heidi_> k
[09:18:04 CDT(-0500)] <jessm> heidi_: there are headers that explain the diff.
[09:18:07 CDT(-0500)] <jessm> and i'm fine with that
[09:19:03 CDT(-0500)] <jessm> jamon: the site is pretty slow lately – is something happening currently?
[09:19:43 CDT(-0500)] <greggy> jessm: I found restarting my browser sped things up. I think there's some JS problems in the JM backend
[09:19:58 CDT(-0500)] <jessm> ok, i'll try that
[09:20:13 CDT(-0500)] <heidi_> greggy smriti is online and checking out online resources now
[09:20:14 CDT(-0500)] <jamon> not that i know of
[09:20:33 CDT(-0500)] <greggy> heidi_: k
[09:20:57 CDT(-0500)] <heidi_> she fixed it!
[09:21:27 CDT(-0500)] <heidi_> greggy in blog category..pagination was on
[09:22:05 CDT(-0500)] <greggy> heidi_: Ah!
[10:27:35 CDT(-0500)] <jessm> heidi_: what's left on the site?
[10:28:22 CDT(-0500)] <heidi_> jessm once my ftp works again (need jamon) i'll fix the max # chars for the search, but just looking at it on diff browsers then i think we're good
[10:28:45 CDT(-0500)] <jessm> what happened to ftp?
[10:28:54 CDT(-0500)] <heidi_> i dunno, i think i got blocked or something
[10:46:03 CDT(-0500)] <jessm> can anyone see greg or jamon wandering around with a camera?
[10:48:17 CDT(-0500)] <colinclark> Hey Bosmon, are you there?
[10:48:48 CDT(-0500)] <Bosmon> Yes, I am here
[10:49:11 CDT(-0500)] <colinclark> We talked the other day about event binding
[10:49:18 CDT(-0500)] <Bosmon> We did
[10:49:34 CDT(-0500)] <colinclark> I was hoping for some declarative way to bind a listener from component B to an event on component A
[10:50:22 CDT(-0500)] <colinclark> Component B has an interesting relationship with component A
[10:50:26 CDT(-0500)] <Bosmon>
[10:50:36 CDT(-0500)] <colinclark> Component A defines a series of shared events
[10:50:45 CDT(-0500)] <colinclark> which many subcomponents use in various ways
[10:50:50 CDT(-0500)] <colinclark> either firing them or listening for them, or both
[10:51:05 CDT(-0500)] <colinclark> So Component B (a.k.a. the FileQueueView) is interested in firing one event
[10:51:14 CDT(-0500)] <colinclark> while listening to several more
[10:51:27 CDT(-0500)] <colinclark> event binding for the former case has been excellent
[10:51:41 CDT(-0500)] <colinclark> In effect, the FileQueueView just has one event--the one it fires
[10:52:04 CDT(-0500)] <colinclark> previously, it was using returnedOptions to bind its listeners to Component A (a.k.a. the Uploader)
[10:52:19 CDT(-0500)] <Bosmon> Yes
[10:52:19 CDT(-0500)] <colinclark> I actually think this likely broken recently
[10:52:24 CDT(-0500)] <Bosmon> That Epicyclic Phenomenon
[10:52:28 CDT(-0500)] <colinclark> yes
[10:52:37 CDT(-0500)] <colinclark> So, ultimately, to get things up and running
[10:52:37 CDT(-0500)] <Bosmon> Hmm, if it has, it should show up in the Reorderer tests
[10:52:42 CDT(-0500)] <Bosmon> I will run them to check
[10:52:42 CDT(-0500)] <colinclark> Interesting
[10:52:45 CDT(-0500)] <colinclark> thanks
[10:53:23 CDT(-0500)] <colinclark> Ultimately, I ended up using event binding to "give" FileQueueView all of the events it wants to listen to
[10:53:31 CDT(-0500)] <colinclark> but it makes for a more brittle testing situation
[10:53:40 CDT(-0500)] <Bosmon> Yes - I have horribly broken LayoutReorderer tests
[10:53:42 CDT(-0500)] <Bosmon> Sorry, folks
[10:53:50 CDT(-0500)] <colinclark> since I now need to provide these events to the FileQueueView
[10:54:00 CDT(-0500)] <colinclark> if only to allow a call to .addListener()
[10:54:18 CDT(-0500)] <colinclark> If returnedOptions are going the way of the Dodo, I wonder if I really want to use thenm
[10:54:27 CDT(-0500)] <colinclark> But I was unable to find a workable alternative
[10:55:11 CDT(-0500)] <colinclark> Now we had talked the other day about one possibility...
[10:55:21 CDT(-0500)] <colinclark> which was simply to setup a listeners block in the parent component--Uploader
[10:55:35 CDT(-0500)] <Bosmon> I thought the idea was to set it up in a child?
[10:55:36 CDT(-0500)]

[10:55:40 CDT(-0500)] <colinclark> hmm
[10:55:54 CDT(-0500)] <colinclark> Perhaps I managed to scramble myself over the course of the weekend
[10:56:00 CDT(-0500)] <Bosmon> In such a way that the child "resolves away" through demands if the environment is not right
[10:56:10 CDT(-0500)] <colinclark> Ah, yes
[10:56:16 CDT(-0500)] <Bosmon> Or conversely, starts out as nothing, but when not running as a test, resolves to something
[10:56:21 CDT(-0500)] <colinclark> We had talked about a "event binder" component
[10:56:24 CDT(-0500)] <Bosmon> yes
[10:56:42 CDT(-0500)] <colinclark> Can you walk me through this idea again, briefly?
[10:56:51 CDT(-0500)] <colinclark> I'm sure it will be useful for others here to be aware of, too
[10:56:56 CDT(-0500)] <Bosmon> Yes
[10:58:22 CDT(-0500)] <Bosmon> So, the situation is, that in some contexts (such as the live app) "a component wants" or rather "we want" some listeners it has bound to events which are fired from elsewhere
[10:58:39 CDT(-0500)] <colinclark> Are you saying components don't have free will?
[10:58:42 CDT(-0500)] <Bosmon> In other situations, such as testing, the binding target for the events may not exist
[10:58:58 CDT(-0500)] <colinclark> Yes, that's right
[10:59:02 CDT(-0500)] <Bosmon> This is a classic situation which should be resolved via "demands blocks"
[10:59:25 CDT(-0500)] <Bosmon> There is also another issue in that it is currently not very safe or stable to make IoC references from one component to ITSELF
[10:59:35 CDT(-0500)] <Bosmon> That is, in particular, as part of its options, to refer to another part of the same options structure
[10:59:43 CDT(-0500)] <colinclark> Exactly! The behaviour is contextual: "I want when we're using the full-on Uploader, but not in a unit test or with the simple Uploader"
[11:00:01 CDT(-0500)] <Bosmon> So - this suggests that the event binding be done in a THIRD place
[11:00:02 CDT(-0500)] <colinclark> Not safe or stable because why?
[11:00:12 CDT(-0500)] <Bosmon> Because we don't yet have the "globally ginger world"
[11:00:20 CDT(-0500)] <Bosmon> Right now the initialisation of a component happens in discrete phases
[11:00:25 CDT(-0500)] <Bosmon> FIRSTLY, options expansion occurs
[11:00:42 CDT(-0500)] <Bosmon> This firstly, very closely followed by event instantiation and listener merging
[11:00:54 CDT(-0500)] <Bosmon> SECONDLY, initialisation of IoC-driven subcomponents and invokers occurs
[11:01:28 CDT(-0500)] <Bosmon> this second phase is what is called "ginger" - in fact we have to be clear, this SECOND phase is actually occuring "simultaneously across the whole IoC tree of subcomponents"
[11:01:54 CDT(-0500)] <Bosmon> If any part of the configuration makes a reference to any other subcomponent in the tree, instantiation will immediately switch to that subcomponent if it can, so that the reference resolves
[11:02:04 CDT(-0500)] <colinclark> So, to put it in other words...
[11:02:10 CDT(-0500)] <Bosmon> And this is also true for references to other subcomponents of the SAME component
[11:02:17 CDT(-0500)] <Bosmon> However, the same is not true currently of options expansion
[11:02:34 CDT(-0500)] <Bosmon> Making a reference from one part of a component's options to some other part of the same component's options will fail
[11:02:37 CDT(-0500)] <colinclark> You're using the word "ginger" to mean that the framework will look for references to a thing, and ensure that it has been instantiated in the right order
[11:02:38 CDT(-0500)] <Bosmon> Because the "options have not arrived yet"
[11:02:41 CDT(-0500)] <Bosmon> Yes
[11:03:25 CDT(-0500)] <colinclark> Meaning, if Component A needs something from Component B, we need to ensure that Component B is fully instantiated first
[11:03:26 CDT(-0500)] <colinclark> ok
[11:03:36 CDT(-0500)] <Bosmon> So for these reasons, and others, it might be best to put responsibility for the binding of component A onto Component B into a third component, component C
[11:03:56 CDT(-0500)] <Bosmon> If C senses the simultaneous presence of A and B, which it can do, via a demands block, it will do the binding
[11:04:07 CDT(-0500)] <Bosmon> If either party is missing, it will resolve to an empty component
[11:04:25 CDT(-0500)] <colinclark> C will resolve to an empty component, you mean?
[11:04:54 CDT(-0500)] <colinclark> So, there's some subtlety here, if I'm understanding it correctly
[11:05:03 CDT(-0500)] <colinclark> C will never actually "be" a component, right?
[11:05:19 CDT(-0500)] <colinclark> It will just be two demands blocks, resolving onto fluid.emptyComponent
[11:05:32 CDT(-0500)] <Bosmon> Well, you will have to give a name to C
[11:05:36 CDT(-0500)] <colinclark> right
[11:05:38 CDT(-0500)] <Bosmon> So that you have something to issue the demands block against
[11:05:41 CDT(-0500)] <colinclark> Right
[11:05:52 CDT(-0500)] <Bosmon> Now in the world of "autoInit" it is arguable whether anything actually "is" a component
[11:05:52 CDT(-0500)] <colinclark> So, in the demands block for the case of both A and B being present
[11:05:56 CDT(-0500)] <colinclark> lol
[11:06:07 CDT(-0500)] <colinclark> I will have options that use the new event binding feature
[11:06:22 CDT(-0500)] <colinclark> so I can, on the left hand side of a listeners block, actually refer to A's event names
[11:06:28 CDT(-0500)] <colinclark> and on the right hand side, and refer to B's listeners
[11:06:30 CDT(-0500)] <colinclark> is that correct?
[11:07:09 CDT(-0500)] <Bosmon> That's correct, yes
[11:07:17 CDT(-0500)] <colinclark> okay
[11:07:29 CDT(-0500)] <colinclark> Perhaps I'll whip up a pastie with a sketch to make sure I'm 100% clear
[11:07:31 CDT(-0500)] <colinclark> gimme one sec
[11:07:52 CDT(-0500)] <colinclark> In the meantime, michelled, does this jive with your memory of the conversation?
[11:08:00 CDT(-0500)] <colinclark> She's probably at CSpace standup
[11:12:53 CDT(-0500)] <colinclark> Bosmon: Does this seem about right?
[11:12:54 CDT(-0500)] <colinclark> http://pastie.org/1674920
[11:16:05 CDT(-0500)] <Bosmon> yes, although you need to make the thing at least an "eventedComponent" so it will even perform any event processing
[11:16:10 CDT(-0500)] <Bosmon> Which you should do in its defaults
[11:16:16 CDT(-0500)] <heidi_> justin_o can greggy updated the computer across from you to have IE9?
[11:16:25 CDT(-0500)] <Bosmon> Oh wait
[11:16:25 CDT(-0500)] <heidi_> not sure if that's set up to be a certain test comp yet
[11:16:28 CDT(-0500)] <Bosmon> Well, this is interesting
[11:16:32 CDT(-0500)] <colinclark> Looks like emptySubcomponent is too empty
[11:16:33 CDT(-0500)] <colinclark>
[11:16:57 CDT(-0500)] <Bosmon> Yes, I think this is best
[11:17:04 CDT(-0500)] <justin_o> heidi_: sure.. i think it has IE 9 RC 1 on it.. so he can feel free to update that to the Final Release of IE 9
[11:17:08 CDT(-0500)] <Bosmon> Yes... emptySubcomponent is not really a component of any kind
[11:17:20 CDT(-0500)] <heidi_> justin_o is there a pw on that comp?
[11:17:20 CDT(-0500)] <Bosmon> I guess we should think about where this further Epicycle sits in our new world
[11:17:28 CDT(-0500)] <justin_o> heidi_: i don't think so
[11:17:35 CDT(-0500)] <Bosmon> But "flieQueueView.eventBinder" should really be an "autoinit eventedComponent"
[11:17:38 CDT(-0500)] <colinclark> So, this is blowing my mind slightly, being new to Graded components
[11:17:45 CDT(-0500)] <colinclark> I'm going to make a thing, without making a thing
[11:17:58 CDT(-0500)] <Bosmon> And it is just the listeners block which is demanded
[11:18:09 CDT(-0500)] <Bosmon> Also, you don't need to do this args: [null junk any more
[11:18:14 CDT(-0500)] <Bosmon> You can just write "options" in the demands block
[11:18:19 CDT(-0500)] <colinclark> ok
[11:18:27 CDT(-0500)] <colinclark> can you tweak this example for me real quick?
[11:18:30 CDT(-0500)] <Bosmon> This was something that once assurec anastasiac actually worked, whereas it now actually does
[11:18:36 CDT(-0500)] <colinclark> and show me what you mean?
[11:18:41 CDT(-0500)] <Bosmon> Sure
[11:18:44 CDT(-0500)] <colinclark> thanks, dude
[11:20:24 CDT(-0500)] <Bosmon> http://pastie.org/1674953
[11:20:40 CDT(-0500)] <Bosmon> This should work
[11:20:43 CDT(-0500)] <colinclark> It's really brain bending
[11:20:44 CDT(-0500)] <Bosmon> And if it doesn't work, it is a bug
[11:20:50 CDT(-0500)] <colinclark> I immediately think
[11:20:57 CDT(-0500)] <colinclark> with the exception of fluid.emptySubcomponent
[11:21:02 CDT(-0500)] <Bosmon> Yes well, in the old days there was a clear distinction between "something which was a component" and "something which was not a component"
[11:21:04 CDT(-0500)] <colinclark> if I want a thing, I have to write a creator function for it
[11:21:07 CDT(-0500)] <colinclark> yes
[11:21:15 CDT(-0500)] <Bosmon> Given that the former clearly had some CODE written for it
[11:21:15 CDT(-0500)] <colinclark> Now I just write some configuration, and off it goes
[11:21:22 CDT(-0500)] <colinclark> Now, to be fair, this thing doesn't really DO anything
[11:22:00 CDT(-0500)] <colinclark> So, now, I could make a component like this this that actually DOES something, right?
[11:22:07 CDT(-0500)] <colinclark> I'd specify a "finalInitFunction" option
[11:22:09 CDT(-0500)] <Bosmon> Sure... you could make a "renderer component"
[11:22:17 CDT(-0500)] <colinclark> and would then have an opportunity to add methods to it
[11:22:19 CDT(-0500)] <colinclark> is that right?
[11:22:21 CDT(-0500)] <Bosmon> Oh yes, if you want actual CODE, you could write a finalInitFunction
[11:22:37 CDT(-0500)] <colinclark> So, why would I do it this way instead of just writing a creator function?
[11:22:38 CDT(-0500)] <Bosmon> Or a plain initFunction
[11:23:02 CDT(-0500)] <Bosmon> Well, in future, writing a creator function will be "strongly deprecated"
[11:23:04 CDT(-0500)] <colinclark> initFunction and finalInitFunction run at different phases of initialization, I guess?
[11:23:07 CDT(-0500)] <Bosmon> if not actually physically illegal
[11:23:28 CDT(-0500)] <Bosmon> There are some strong limitations on what the IoC system can do if you have written your own creator function
[11:23:41 CDT(-0500)] <colinclark> So, this seems like a good opportunity for you to take a quick minute to elaborate on "why we would want this?"
[11:23:43 CDT(-0500)] <Bosmon> And there are ways you can do things that will screw it up... for example, if you write a creator function that does not actually create something
[11:23:54 CDT(-0500)] <Bosmon> Or, a creator function that instead creates something ELSE
[11:24:22 CDT(-0500)] <Bosmon> For example, by pretending to be the gardener
[11:24:30 CDT(-0500)] <Bosmon> Yes, why do we want fire that can be fitted nasally
[11:24:33 CDT(-0500)] <colinclark> indeed
[11:24:41 CDT(-0500)] <colinclark> At a glance, this feels a bit like our first encounter with Dojo
[11:24:48 CDT(-0500)] <colinclark> Where we had all these things we had to do
[11:24:49 CDT(-0500)] <Bosmon> So, a sort of long-range discussion is one that we had privately a while back
[11:24:52 CDT(-0500)] <colinclark> and for little apparent reason
[11:24:59 CDT(-0500)] <colinclark> but keep going, sorry
[11:25:13 CDT(-0500)] <Bosmon> Which is, "what if Javascript VMs change in a significant way in the future, such that a strongly preferred way of writing things is via new() and bind()"
[11:25:35 CDT(-0500)] <Bosmon> One conceivable, though very distant, advantage of this approach, of "hiding the point of creation" is that it gives us resistance to changes like that
[11:25:47 CDT(-0500)] <colinclark> right
[11:25:48 CDT(-0500)] <Bosmon> Secondly - lots of the code we write in creator functions is just "noise"
[11:25:58 CDT(-0500)] <Bosmon> We have to call a particular method with particular parameters
[11:26:05 CDT(-0500)] <colinclark> It's an abstraction on the mechanics of how objects get created
[11:26:12 CDT(-0500)] <Bosmon> We then have to call another method, with arguments based on stuff that we got from the first function
[11:26:20 CDT(-0500)] <Bosmon> Then we might do some other stuff
[11:26:29 CDT(-0500)] <Bosmon> Finally, we need to remember to return the thing we got from the first function
[11:26:37 CDT(-0500)] <Bosmon> It is all very distressingly "sequential"
[11:27:00 CDT(-0500)] <Bosmon> And the more "sequential" code we right, the less free the IoC system is to reorder operations in a way which is "appropriate"
[11:27:14 CDT(-0500)] <Bosmon> Also, the more sequential code we write, we have to debug it
[11:27:26 CDT(-0500)] <Bosmon> There's clearly nothing to debug in the example I pasted... except, of course, the IoC system itself
[11:27:50 CDT(-0500)] <colinclark> sure
[11:28:01 CDT(-0500)] <colinclark> Can you, though, boil it down to some active benefits that a developer gets from the start?
[11:28:06 CDT(-0500)] <colinclark> "No testing" is clearly one
[11:28:08 CDT(-0500)] <colinclark> anything else?
[11:28:27 CDT(-0500)] <Bosmon> Well, they get an absence of having to write boilerplate code, in favour of just writing configuration
[11:28:39 CDT(-0500)] <Bosmon> They may or may not see that as an active benefit, depending on their mentality
[11:29:03 CDT(-0500)] <colinclark> Can you imagine any way to accommodate both?
[11:29:20 CDT(-0500)] <colinclark> In other words, to get us to a point where we don't have to actively discourage the use of creator functions?
[11:29:25 CDT(-0500)] <Bosmon> Ah, I see
[11:29:27 CDT(-0500)] <colinclark> I'm trying to imagine a spectrum, or an on-ramp
[11:29:27 CDT(-0500)] <Bosmon> I don't think so, no
[11:29:33 CDT(-0500)] <colinclark> How come?
[11:29:52 CDT(-0500)] <Bosmon> Well, I think it is ultimately essential that creator functions are deprecated
[11:29:59 CDT(-0500)] <Bosmon> I guess we can always allow their use, for "beginning users"
[11:30:18 CDT(-0500)] <Bosmon> That is, I imagine we need not ever produce a version of the framework in which they are completely forbidden
[11:30:30 CDT(-0500)] <Bosmon> but I imagine we will get to the point soon where we will "actively discourage" them
[11:31:24 CDT(-0500)] <Bosmon> That is, when we produce code samples of "how we recommend you use the framework", they will not show them
[11:31:45 CDT(-0500)] <colinclark> So far, your main point was that they could actively "screw IoC up"
[11:31:49 CDT(-0500)] <colinclark> in a couple of scenarios
[11:31:58 CDT(-0500)] <colinclark> Creators that don't create
[11:31:59 CDT(-0500)] <Bosmon> Well, I think it is all part of the same point
[11:32:01 CDT(-0500)] <colinclark> or create something else
[11:32:05 CDT(-0500)] <Bosmon> They "introduce an avenue for error"
[11:32:10 CDT(-0500)] <colinclark> Okay
[11:32:15 CDT(-0500)] <Bosmon> Which is the same as the "testing" point
[11:32:18 CDT(-0500)] <colinclark> So, assuming a creator doesn't do such things
[11:32:27 CDT(-0500)] <colinclark> Why is it really an issue?
[11:32:36 CDT(-0500)] <Bosmon> Why is it really an issue that error might occur?
[11:32:44 CDT(-0500)] <colinclark> Well, yes
[11:32:52 CDT(-0500)] <colinclark> this is actually an interesting point we've debated plenty of times
[11:32:57 CDT(-0500)] <Bosmon> Surely the only goal of coding is to progress so that it is "inconceivable that errors may occur"
[11:33:02 CDT(-0500)] <colinclark> It's clear why we'd want the declarative form
[11:33:04 CDT(-0500)] <Bosmon> Rather than just merely assuring people that they don't
[11:33:08 CDT(-0500)] <colinclark> and quite clear why we'd want to use it
[11:33:21 CDT(-0500)] <colinclark> less clear that "making it illegal" provides us with any direct benefit
[11:33:23 CDT(-0500)] <colinclark> if you see what I mean
[11:33:28 CDT(-0500)] <Bosmon> Yes
[11:33:38 CDT(-0500)] <Bosmon> Well, I think I said that we will never quite "make it illegal"
[11:33:46 CDT(-0500)] <colinclark> Clearly I am keen to use idioms that reduce the likelihood of error
[11:34:01 CDT(-0500)] <colinclark> The core decisions of Infusion have all been based on this as a central criteria
[11:34:01 CDT(-0500)] <Bosmon> But will not positively recommend that people do it
[11:34:01 CDT(-0500)] <colinclark>
[11:34:10 CDT(-0500)] <Bosmon> Unless, as you say, this is some kind of "on-ramp"
[11:34:16 CDT(-0500)] <Bosmon> but the question is, how long, and how shallow is this ramp
[11:34:22 CDT(-0500)] <colinclark> Yes, I just want to make sure we're continue to see that "spectrum" or "on-ramp"
[11:34:37 CDT(-0500)] <colinclark> I want to make it possible to migrate code without fully rewriting it
[11:34:49 CDT(-0500)] <colinclark> And to enable the use of the framework in a way that isn't all or nothing
[11:34:52 CDT(-0500)] <Bosmon> Right
[11:34:59 CDT(-0500)] <Bosmon> Well, that has always been the way the framework is...
[11:35:06 CDT(-0500)] <Bosmon> The framework is clearly going to stay the framework
[11:35:15 CDT(-0500)] <Bosmon> But our recommendations are not always going to stay our recommendations
[11:35:22 CDT(-0500)] <colinclark> lol
[11:36:14 CDT(-0500)] <Bosmon> Other things, though, I think are going to become illegal... such as issuing a "defaults" block without any gradeNames
[11:36:20 CDT(-0500)] <Bosmon> It's "no skin off people's nose" to do that
[11:36:28 CDT(-0500)] <Bosmon> And it heads off any number of potentially awful problems
[11:37:57 CDT(-0500)] <Bosmon> Well, perhaps we can be milder there too
[11:38:21 CDT(-0500)] <Bosmon> Rather than forbidding their absence, we can just forbid the attempt to use the IoC system with an ungraded component
[11:38:29 CDT(-0500)] <colinclark> I think it's the sort of thing that will need lots of advanced notice to our users
[11:38:31 CDT(-0500)] <jhung> anastasiac: ping
[11:38:41 CDT(-0500)] <colinclark> Since there are undoubtedly quite a large number of components out in the wild that aren't using IoC
[11:38:43 CDT(-0500)] <anastasiac> jhung, polo
[11:38:50 CDT(-0500)] <Bosmon> Yes, it would be a kind of "Fluid 2.0" transition
[11:38:58 CDT(-0500)] <colinclark> I imagine we'll have to get IoC to a point where it's at production status, plus some extra time
[11:39:01 CDT(-0500)] <colinclark> yep, that seems about right
[11:39:15 CDT(-0500)] <jhung> anastasiac, I was going to put the "Under the Hood" stuff under the Developer Guide and mock it up. Any thoughts before I attempt this?
[11:39:50 CDT(-0500)] <anastasiac> jhung, that seems quite reasonable, especially if that's the sense you got from your survey yesterday
[11:40:02 CDT(-0500)] <colinclark> Bosmon: Okay, this has been really great
[11:40:09 CDT(-0500)] <colinclark> I learned a bit more about Grades
[11:40:14 CDT(-0500)] <colinclark> (still would love a new name)
[11:40:16 CDT(-0500)] <Bosmon> yes, thanks for your Socratic Presentation
[11:40:20 CDT(-0500)] <colinclark> lol
[11:40:30 CDT(-0500)] <colinclark> And learned a new technique for binding events declaratively
[11:40:44 CDT(-0500)] <colinclark> and covered a few of the motivations for our new framework features
[11:40:45 CDT(-0500)] <colinclark> all good
[11:41:00 CDT(-0500)] <colinclark> Bosmon: Anything else we should cover while we're in a chatty mood?
[11:41:17 CDT(-0500)] <jhung> anastasiac: Yeah. It's all developer resources to them.
[11:41:18 CDT(-0500)] <Bosmon> Well, we still need to talk about "how we define methods"
[11:41:27 CDT(-0500)] <anastasiac> makes sense
[11:41:27 CDT(-0500)] <Bosmon> But that wont' be "bite-sized"
[11:41:39 CDT(-0500)] <jhung> anastasiac: Would a better title be "How Infusion Works" or something to that effect?
[11:42:04 CDT(-0500)] <anastasiac> jhung, possibly - still not sure what a good title would be. That's probably better, as a start
[11:42:22 CDT(-0500)] <Bosmon> We need some method of writing methods which is i) not vastly more verbose or vastly less performant than what you get from "old-style creator functions", but ii) is visible to readers of the component as well as the IoC system
[11:42:27 CDT(-0500)] <colinclark> jhung, anastasiac: From the peanut gallery, I like "How Infusion Works" better than "Under the Hood"
[11:42:45 CDT(-0500)] <anastasiac> me too, thanks colinclark
[11:43:11 CDT(-0500)] <colinclark> Bosmon: Can you elaborate on this visibility point?
[11:43:12 CDT(-0500)] <jhung> anastasiac: Ok. We'll run with that for now.
[11:43:25 CDT(-0500)] <Bosmon> It is part of the "gingerness" point we were talking about before
[11:43:29 CDT(-0500)] <colinclark> I guess you're saying that "visible to readers" and "visible to IoC" might be at odds with each other?
[11:43:44 CDT(-0500)] <Bosmon> Well not really, they will both tend in the same direction
[11:43:56 CDT(-0500)] <Bosmon> It's really the verbosity and performance issues which fight against visibility
[11:44:04 CDT(-0500)] <Bosmon> We could argue that what we do right now is not actually visible AT ALL
[11:44:15 CDT(-0500)] <Bosmon> Since methods are all embodied in private code written in the creator function
[11:44:22 CDT(-0500)] <colinclark> I think I have probably argued that many times, in fact
[11:44:23 CDT(-0500)] <Bosmon> You need to read the source code in order to know what methods exist
[11:44:48 CDT(-0500)] <Bosmon> And without making some kind of custom docs tool which parses the source, there's not even any automated way to document them
[11:45:08 CDT(-0500)] <colinclark> Hmm
[11:45:15 CDT(-0500)] <colinclark> You're imagining something here...
[11:45:17 CDT(-0500)] <colinclark> I was about to ask
[11:45:23 CDT(-0500)] <colinclark> "What other techniques are there, though? Read the source or read the docs"
[11:45:27 CDT(-0500)] <Bosmon> So "visibility to users" and "visibility to IoC" I think are the same side of the same coin
[11:45:48 CDT(-0500)] <colinclark> What does the IoC need to know about methods?
[11:45:49 CDT(-0500)] <Bosmon> Well, it would be much easier to map docs onto code, the more the structure of our code becomes declarative
[11:45:59 CDT(-0500)] <Bosmon> Well, for a start, it needs to know that they exist
[11:46:11 CDT(-0500)] <Bosmon> For an extra bonus, it might know something about the kinds of arguments they accept
[11:46:31 CDT(-0500)] <Bosmon> Although that's probably going a bit far, for Javascript
[11:46:40 CDT(-0500)] <Bosmon> And really WOULD amount to creating "some kind of type system"
[11:46:55 CDT(-0500)] <Bosmon> But the question is, whether "defining a method" really requires some kind of lifecycle activity
[11:47:10 CDT(-0500)] <Bosmon> That is, at the point of definition, whether the method needs to know anything else from the environment other than the bare "that" reference
[11:47:23 CDT(-0500)] <Bosmon> MOST methods that people have defined so far, are of the kind that they would not
[11:47:47 CDT(-0500)] <Bosmon> But of course they were not clearly visibly known to be so
[11:47:49 CDT(-0500)] <Bosmon> People just "hoped"
[11:48:03 CDT(-0500)] <Bosmon> This is what led to more of the "sequentialism" we saw in creator functions
[11:48:33 CDT(-0500)] <Bosmon> People "hoped" that there were not unexpected side-effects caused by the defining of methods... and that the material in the creator function could be arbitrarily reordered
[11:48:36 CDT(-0500)] <Bosmon> But they could never "know"
[11:48:53 CDT(-0500)] <Bosmon> And since it all occured in "private code" in any case, it simply didn't matter
[11:48:56 CDT(-0500)] <colinclark> I guess it's something always your mind as you're building a component
[11:49:02 CDT(-0500)] <Bosmon> Nothing was going to come along and try to reorder the creator function
[11:49:20 CDT(-0500)] <colinclark> So, I think maybe my question wasn't quite right...
[11:49:35 CDT(-0500)] <colinclark> Why does the IoC system need to know anything about methods?
[11:49:39 CDT(-0500)] <colinclark> What features will this provide?
[11:49:40 CDT(-0500)] <colinclark> etc.
[11:49:55 CDT(-0500)] <Bosmon> Yes, it will provide the feature of being able to do the kind of thing we just pastie'd more reliably
[11:50:22 CDT(-0500)]

<Bosmon> Even now, for example, we need to be "careful" about your "

Unknown macro: {fileQueueView}

.meow" operation

[11:50:44 CDT(-0500)] <Bosmon> Depending on the exact point in the lifecycle that fileQueueView is investigated, there will be no "meow" member on it
[11:50:53 CDT(-0500)] <Bosmon> Especially, if it is investigated immediately after options merging
[11:51:16 CDT(-0500)] <Bosmon> And it will actually make a difference, whether you use "initFunction" or "finalInitFunction"
[11:51:26 CDT(-0500)] <Bosmon> These are kinds of manual names for particular points in the construction workflow
[11:51:50 CDT(-0500)] <Bosmon> Whereas it would all be much clearer and safer if you could advertise to the IoC system that "these methods should and will exist" and leave it to get on with it
[11:52:36 CDT(-0500)] <Bosmon> Users should have to bother themselves with the exact details, or even any particularly exact understanding of the exact sequence in which a component is constructed
[11:52:39 CDT(-0500)] <Bosmon> shouldn't
[11:52:56 CDT(-0500)] <Bosmon> But right now, especially whilst we are still in the world of "manual creator functions", they do
[11:53:12 CDT(-0500)] <Bosmon> And until we come up with a good way of expressing "how to define methods", they still will, to some extent
[11:54:41 CDT(-0500)] <colinclark> So, you're implicitly arguing against doing what most other frameworks do
[11:54:52 CDT(-0500)] <colinclark> which is to define a fixed series of lifecycle points
[11:54:52 CDT(-0500)] <colinclark> a
[11:55:03 CDT(-0500)] <colinclark> and have users be explicitly familiar with them
[11:55:05 CDT(-0500)] <colinclark> is that right?
[11:55:14 CDT(-0500)] <Bosmon> Yes, or at least, expecting that this fixed series is something that exists in a "lively way in the world of the users"
[11:55:34 CDT(-0500)] <colinclark> Why not take that approach?
[11:55:43 CDT(-0500)] <Bosmon> The users should simply designate "that a particular collection of things should be done" and it is the job of the framework to get on with figuring out how they should be scheduled
[11:56:03 CDT(-0500)] <Bosmon> Well, for a start, it is very brittle, and is the first point that fracture points open up as a framework evolves over time
[11:56:17 CDT(-0500)] <Bosmon> JSF, for example, defined exactly SEVEN lifecycle points, all with particular names
[11:56:30 CDT(-0500)] <Bosmon> If you wanted to "get with the framework" you had to decide how you aligned with these seven points
[11:56:42 CDT(-0500)] <Bosmon> The possibly more profound reason is related to the failure of Moore's law
[11:57:03 CDT(-0500)] <Bosmon> Eventually, over time, and possibly not even still in our lifetimes, "sequential code" will gradually start to become progressively more cursed
[11:57:30 CDT(-0500)] <Bosmon> Although it was long-delayed, the gradual move towards parallelism is finally underway...
[11:57:32 CDT(-0500)] <colinclark> Due to the need to parallelize code over multiple cores?
[11:57:37 CDT(-0500)] <colinclark> ah yes
[11:57:38 CDT(-0500)] <Bosmon> The "octocore" machine is no longer a crazy oddity
[11:57:47 CDT(-0500)] <Bosmon> Even the most basic laptop now comes with 2 cores
[11:57:50 CDT(-0500)] <colinclark> Yes
[11:57:59 CDT(-0500)] <colinclark> Your average MacBook now ships with 4
[11:58:02 CDT(-0500)] <Bosmon> I'm sure within 10 years we will be routinely seeing consumer-grade machines with hundreds of cores
[11:58:15 CDT(-0500)] <Bosmon> Suddenly code which is written sequentially will start to look like complete crap
[11:58:19 CDT(-0500)] <colinclark> Yeah
[11:58:23 CDT(-0500)] <colinclark> code today just can't scale to it
[11:58:29 CDT(-0500)] <colinclark> the complexity will be insane
[11:58:37 CDT(-0500)] <Bosmon> So - another crucial reason to abstract over sequentialism is raised by frameworks such as Node
[11:58:44 CDT(-0500)] <Bosmon> Which take a completely DIFFERENT approach to parallelism
[11:58:54 CDT(-0500)] <Bosmon> In that any code which performs I/O is required to immediately suspend
[11:59:04 CDT(-0500)] <Bosmon> If your code is written in CODE, this is the kind of detail which you can't abstract over
[11:59:14 CDT(-0500)] <Bosmon> Either every function call you write contains a "continuation callback" or it DOESN'T
[11:59:22 CDT(-0500)] <Bosmon> That aspect is baked in stone the moment you write it
[11:59:49 CDT(-0500)] <Bosmon> And, despite what Node proponents say, writing in this style is generally pretty noisy and undesirable
[12:00:05 CDT(-0500)] <Bosmon> People wouldn't naturally do it unless they had a clear expectation they were writing for an "evented" architecture
[12:00:36 CDT(-0500)] <colinclark> It might be easier to deal with than threads in some cases
[12:00:37 CDT(-0500)] <Bosmon> Writing code in "configuration" without explicit sequentialism makes it agnostic as to what parallelism model it is expecting
[12:00:48 CDT(-0500)] <colinclark> but we know from experience that it's complex
[12:01:03 CDT(-0500)] <Bosmon> It could deploy on threads, if there are threads, or it could be evented, if it is on an evented platform
[12:01:09 CDT(-0500)] <colinclark> right
[12:01:16 CDT(-0500)] <Bosmon> it could even use.... "co-routines".... should they ever appear in a popular JS platform
[12:02:03 CDT(-0500)] <Bosmon> But whilst the basic component workflow is expressed as "one damn thing after another" it would always be tied to the particular model it was written for
[12:03:35 CDT(-0500)] <Bosmon> Since all things which used to be called "side-effects" in the IoC system are actually explicit, it is possible to make informed decisions about when particular operations can be scheduled, and which can proceed in parallel
[12:03:52 CDT(-0500)] <Bosmon> As a result of the IoC tree as a whole, as well as the individual model for each component, using what we call the "transparent state model"
[12:05:53 CDT(-0500)] <colinclark> Ok
[12:05:59 CDT(-0500)] <colinclark> That's a pretty interesting answer
[12:10:30 CDT(-0500)] <Bosmon> I guess the most immediate aspects of these issues are i) the imminent move of our code over to Node.js and ii) the implementation of what has been called "renderer antigens"
[12:11:41 CDT(-0500)] <justin_o> heidi_: wondering if you've had a chance to look at my github branch
[12:11:56 CDT(-0500)] <heidi_> justin_o once idrc goes live... which should be soon!
[12:12:42 CDT(-0500)] <justin_o> heidi_: okay, thanks
[12:37:25 CDT(-0500)] <justin_o> anastasiac: can these issues be moved to 1.4 http://issues.fluidproject.org/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=project+%3D+FLUID+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%221.3.1%22+ORDER+BY+priority+DESC&amp;mode=hide
[12:38:18 CDT(-0500)] <anastasiac> justin_o, they didn't get done for 1.3.1, and they still need to be done, so yes, let's move them to 1.4
[12:38:35 CDT(-0500)] <justin_o> okay.. thanks.. i can move them
[12:39:20 CDT(-0500)] <colinclark> Seems like a few topics for a nice documentation sprint, eh anastasiac and justin_o?
[12:39:42 CDT(-0500)] <anastasiac> yes, indeed
[12:39:46 CDT(-0500)] <justin_o> yes
[12:39:58 CDT(-0500)] <colinclark> Let's get on organizing that soon
[12:40:00 CDT(-0500)] <colinclark> it'll be fun
[12:40:15 CDT(-0500)] <justin_o> colinclark: how long were planning the sprint to last again?
[12:40:42 CDT(-0500)] <colinclark> Maybe our first could be a one day thing?
[12:40:44 CDT(-0500)] <colinclark> We can see how it goes
[12:40:49 CDT(-0500)] <colinclark> if we want to do two days
[12:40:50 CDT(-0500)] <colinclark> etc.
[12:41:17 CDT(-0500)] <justin_o> okay
[12:42:53 CDT(-0500)] <colinclark> What do you think, anastasiac?
[12:43:37 CDT(-0500)] <anastasiac> excellent idea, colinclark. I'll have a look at other docs tasks and draft a list, and we can think about when we can do this.
[12:43:46 CDT(-0500)] <colinclark> yes
[12:43:49 CDT(-0500)] <colinclark> that would be good
[12:53:58 CDT(-0500)] <justin_o> colinclark: do you know if Bosmon2 will be back soon?
[12:54:12 CDT(-0500)] <colinclark> I don't, no
[12:54:16 CDT(-0500)] <colinclark> I'm sure he will
[12:54:53 CDT(-0500)] <justin_o> i'm going to be going offline in about 30 minutes.. if he hasn't come back online by then could you let him know the layoutreorderer tests are failing
[12:54:54 CDT(-0500)] <justin_o> http://build.fluidproject.org/infusion/tests/component-tests/reorderer/html/LayoutReorderer-test.html
[12:55:04 CDT(-0500)] <justin_o> i'm assuming this has something to do with IoC, but am not sure
[13:08:36 CDT(-0500)] <colinclark> justin_o: He knows, yes
[13:08:50 CDT(-0500)] <justin_o> okay.. that's good thanks
[13:08:53 CDT(-0500)] <colinclark> He broke support for returnedOptions recently
[13:08:57 CDT(-0500)] <colinclark> we chatted about it earlier in the channel
[13:16:56 CDT(-0500)] <justin_o> colinclark: ah okay... so you guys have it covered then.. thanks
[14:07:51 CDT(-0500)] <colinclark> Bosmon2: Just for the record, I was able to implement your suggested "Component C" strategy really easily
[14:08:09 CDT(-0500)] <colinclark> just a quick demands blocks and I was able to remove quite a bit of stuff
[14:08:16 CDT(-0500)] <colinclark> probably shaved 10 lines of code
[14:08:23 CDT(-0500)] <colinclark> maybe a few less
[14:08:23 CDT(-0500)] <jessm> hey y'all, the new IDRC site just went live: http://idrc.ocad.ca – report any edits/suggestions/issues
[14:09:04 CDT(-0500)] <anastasiac> jessm: yay! congratulations to all who contributed
[14:09:05 CDT(-0500)] <jessm> thanks greggy, heidi_ smriti, jamon jameswy colinclark and jan for helping out on it
[14:09:17 CDT(-0500)] <colinclark> y'all did a really nice job
[14:09:50 CDT(-0500)] <colinclark> And this really gives me an incentive to write a new blog post, now that all our feeds are all featured down there at the bottom
[14:10:01 CDT(-0500)] <mlam> jessm: michelled's name has a slash in front of her surname on the staff page
[14:10:13 CDT(-0500)] <jessm> mlam: yeah, just mentioned that to heidi_
[14:10:22 CDT(-0500)] <mlam> k, cool
[14:10:50 CDT(-0500)] <jessm> mlam: good eye
[14:11:10 CDT(-0500)] <mlam>
[14:12:02 CDT(-0500)] <jessm> looks like we have a few link issues and maybe a few missing pics on staff pages
[14:48:42 CDT(-0500)] <jessm> jamon: ping
[14:50:03 CDT(-0500)] <jamon> jessm: ?
[14:50:24 CDT(-0500)] <jessm> just wondered about the twitter thing – i get a feed from it
[14:51:56 CDT(-0500)] <jamon> jessm: i didn't even know it was setup, i haven't seen the site before today, i can investigate, but it will take some time to get up to speed with it
[14:54:23 CDT(-0500)] <jamon> ok jessm, i don't see any feed except snow setup
[14:55:10 CDT(-0500)] <jessm> jamon: three feeds were all working pre-launch
[14:55:15 CDT(-0500)] <jamon> jessm: http://idrc.ocad.ca/administrator/index.php?option=com_newsfeeds
[14:57:45 CDT(-0500)] <anastasiac> jessm, marco?
[14:57:53 CDT(-0500)] <jessm> anastasiac: polo
[14:58:12 CDT(-0500)] <anastasiac> jessm, might you have some time before the day runs out to talk about functional examples?
[14:58:44 CDT(-0500)] <jessm> anastasiac: sure, let's do it now
[14:58:48 CDT(-0500)] <jessm> if that works
[14:58:53 CDT(-0500)] <anastasiac> yes