Disqus - Latest Comments for jmtulloss

Re: An Introduction to JavaScript’s “this”

justin — Tue, 29 Dec 2015 11:58:28 -0000

Not only practical, but a fine work of literature too.

Re: Transducers.js: A JavaScript Library for Transformation of Data

justin — Sat, 07 Feb 2015 22:58:44 -0000

I'm kind of struggling with making some higher level transducers. I'm trying to make a transducer that takes a sequence of transducers and applies them to each value it receives. What might that look like?

It's easy to imagine in an imperative world, but my mind hurts in this world.

Re: Caffeinated Simpleton — Authenticating With Phabricator

justin — Sat, 10 Jan 2015 22:01:50 -0000

I don't recall having that problem, and if I did it's been so long that I don't remember the solution. Hope you figure it out!

Re: Caffeinated Simpleton — Authenticating With Phabricator

justin — Tue, 06 Jan 2015 21:20:44 -0000

Glad you found it useful!

Re: Caffeinated Simpleton — Authenticating With Phabricator

justin — Mon, 25 Aug 2014 14:48:21 -0000

Fixed. Thanks!

Re: Caffeinated Simpleton — Om and Flux (An Ongoing Experiment)

justin — Fri, 08 Aug 2014 11:48:25 -0000

Stores in Flux seem to do two things: provide data and provide methods for mutating data. If data is all uniformly accessed and updated through the cursor API, then in my mind the functionality that's left is the side effects... broadcasting changes to various things that might care (websocket, http API, analytics service, whatever).

Those things could conceivably have dependencies between themselves, and the dependency graph could conceivably be constructed with a pipeline of channels. However, I haven't done anything about that here.

I might dig further into the actual program that I'm writing to find an actual use case before trying to solve this problem. I think a lot of the dependency issues are state dependencies and can be solved by just looking at a cursor into the global state (IE, something updates the derived state, and thing that depends on that just looks at cursor to the derived state)

Re: Caffeinated Simpleton — Om and Flux (An Ongoing Experiment)

justin — Thu, 07 Aug 2014 17:13:32 -0000

You're right, I'll need to think about this more.

Re: Algorithm and Blues

justin — Mon, 05 May 2014 17:28:29 -0000

That's a great post! I'm glad to see more people trying out this approach.

Re: Algorithm and Blues

justin — Tue, 01 Apr 2014 15:31:02 -0000

My example is definitely simplified. In reality you'll probably want to make a shell script that directs the output to some log and calls the appropriate build target.

This is what we use:


exec >> build.log 2>&1
make dev-build
if [ $? -ne 0 ]; then
    tput bel # Make a noise so the dev will look at their terminal
fi

Re: Algorithm and Blues

justin — Tue, 25 Mar 2014 17:41:24 -0000

Yeah, that's really cool!

I, of course, would prefer that it had a CLI interface to rival the JS interface, but the JS interface seems pretty good. It seems like it'd be trivial to start plugging AssetGraph into an existing workflow.

Since you used to be using make, why did you make AssetGraph start building and inlining things instead of just having it take part of the dependency management part?

Re: Algorithm and Blues

justin — Tue, 25 Mar 2014 14:28:47 -0000

Yeah, this is a bit tough. I like your solution, but instead of creating a dependency file for each file, why not just spit them into your Makefile? Something like this might work:


%.css: $(shell ./find-deps %.less)
     # Do the compilation here

For us, we tend to have one file that every less file depends on and then very few that depend on others. So we just manually duplicate those dependencies into the Makefile and assume every less file depends on our one helper less file. If this becomes too burdensome we'll probably have a script look at the dependency graph.

And two seconds later, I realize this has already been solved. It looks like `lessc --depends` will generate exactly what you need! Time to go update our internal Makefile...

Re: Algorithm and Blues

justin — Tue, 25 Mar 2014 14:19:36 -0000

Thanks for asking this question! It's exactly what I would have gone into more depth on if I wanted to write something way too long.

First of all, I really liked your post. I would love it if some powershell-like thing became standard on *nix systems. Seems unlikely to happen anytime soon though.

As for actually addressing this issue, you need a tool that is capable of examining your dependency graph. This is pretty valuable outside of just building things, but it's useful for your build as well. We've ended up spinning our own that will look at our target files (like this one) and then spit those dependencies into our Makefile via a $(shell) call in the Makefile. This is because I was a bit shortsighted years ago and decided not to use require.js, and browserify didn't even exist.

Today I would use one of browserify or require.js. Both include tools for playing with your dependency graph. `browserify --deps` will do exactly what you want, and `r.js` might do what you want but I can't tell by glancing at the documentation.

So we don't really define the dependency graph in make, but we use the definition we have in our program and then make keeps track of it all.

For versioning our bundles, we use .md5 placeholder files. So the rule looks something like this:


%.md5: %
    $(eval VERSION := $(shell $(MD5SUM) $< | cut -d ' ' -f 1))
    cp $< $(basename $<).$(VERSION).js
    printf $(VERSION) > $@

Then our bundles rely on the md5 file existing, which causes the bundle to be built and then versioned.

Re: Algorithm and Blues

justin — Mon, 24 Mar 2014 20:40:11 -0000

Ah, you're right, I'll update with an example from the actual Makefile.

As for the PHONY thing, I was going for an example that just shows running a simple task. You could optimize this example with actual build times, so perhaps an example like starting a server would have been more appropriate.

Re: With Potentially Deadly New Apple Rules Looming, Rdio Revamps Their iPhone App

justin — Thu, 17 Feb 2011 03:32:58 -0000

What is Rdio missing that you would like to see?

Re: Sonos adds Rdio to its streaming music repertoire

justin — Thu, 27 Jan 2011 13:36:23 -0000

http://www.rdio.com/apps/mo...

Re: An Introduction to JavaScript’s “this”

justin — Sat, 18 Dec 2010 21:11:29 -0000

Good catch!

I recently updated the post to use "self" instead of "my", since more and
more people are using that style these days. It's also the style I prefer
now. I guess I missed one!

Re: Bujagali: Incredibly Fast JavaScript Templating

justin — Tue, 19 Oct 2010 15:46:03 -0000

Thanks! That's good to hear.

There are some subtle things that a good understanding of JS helps with (like the difference between 'self' and 'this' in templates) and some crazy ways of designating functions to be called after rendering is complete, but you can definitely get going without using any of that craziness.

On the other hand, a lot of designers are becoming quite fluent in JavaScript, which is awesome. Those guys should (hopefully) have no problem.

Re: Bujagali: Incredibly Fast JavaScript Templating

justin — Tue, 19 Oct 2010 15:05:41 -0000

What it comes down to is that all JavaScript templates, when it comes to actually transforming templates into markup, basically do the same thing. So speed tests against moustache or jQote2 are boring, because while they might all be slightly different, the whole ecosystem around those systems hasn't improved, where it has for Bujagali.

Re: Bujagali: Incredibly Fast JavaScript Templating

justin — Tue, 19 Oct 2010 14:55:26 -0000

Moustache and jQote2 don't provide a built-in way of separating templates from the rest of your markup, meaning they don't cache well. Also, since the templates aren't pre-compiled, there will always be a compilation hit. Bujagali templates can be pre-compiled server side and sent down as regular old JS files. This is what we do at rdio.

It's kind of an entirely different approach, but I'll come up with some numbers and make a new post soon to illustrate the differences.

Re: Caffeinated Simpleton — Cobra is Ready to Release

justin — Sun, 17 Oct 2010 14:52:02 -0000

It's on github: http://github.com/JustinTul...

Re: Java, please stop ruining my fun.

justin — Sat, 12 Jun 2010 21:26:32 -0000

Yes, I should have updated this post after this project came out. I haven't played with leiningen much, but it's clear that the situation is now much better.

Re: An Introduction to JavaScript’s “this”

justin — Sun, 27 Sep 2009 16:32:11 -0000

Updated the first example. Thanks!

Re: An Introduction to JavaScript’s “this”

justin — Sun, 27 Sep 2009 16:28:28 -0000

Yeah, I think you're right DougBTX. I've changed it.

Re: An Introduction to JavaScript’s “this”

justin — Sun, 27 Sep 2009 16:18:56 -0000

You're right that it's unnecessary. I was trying to combine the previous point, but it might just make things more confusing. I might change it.

Re: An Introduction to JavaScript’s “this”

justin — Sun, 27 Sep 2009 06:55:41 -0000

You're right about the order, it's been corrected. I don't really believe in putting millisecond timeouts in examples since it's needlessly detail oriented.