etrinh

Cool project! I haven't seen the idea of drag and drop for building regex's before. I could definitely see this being a helpful tool for people learning regex. Some feedback:

1. The railroad is the intended drag target but is really small, especially compared to the other icons (giant trash can!). This makes it difficult to drag onto, and it's not obvious that that's where you should drag the blocks.

2. Black on brown (ie: railroad and trash can icons) is really hard to see.

3. Highlighting of the matched word (where the "Write text here!" is) seems to be pretty sporadic. It looks like highlighting only changes when the regex changes. I expected to be able to change this field and have the highlight update as I type.

4. Doesn't seem like you can edit the middle of a string in the matching word field (Try editing "Write text here!" to "Write helpful text here!") The cursor keeps jumping to the end of the string.

I used these docs when I was exploring the Immutable.js API! Very helpful, but Immutable just updated to v3 (your docs are v2), which introduces some breaking changes (for example, Vector is now called List). Would you mind updating your docs?

I've been using this library for a project, and here are my thoughts on it:

1. Immutable data structures are a huge win. I can't count the number of times I've been bitten by a bug caused by some subtle mutation that happened in a part of my code that I wasn't expecting.

2. Using this library for data structures everywhere, as a replacement for native JS arrays and objects, requires you to have discipline in naming your variables so that you can infer their types. Things can get pretty frustrating when you try to map over a Set, thinking it's a Map, for example.

3. The most annoying thing might be the documentation, which consists of a type definitions file and liberal comments. It's ok, but hardly a great interface for exploring the API.

Overall, liking the library so far. I think with good, searchable docs (with examples of API usage) this could be something really great.

The app is pretty confusing to use. For those of you stuck like I was, you actually have to complete the tutorial in order to add people and start "slinging."

This looks cool. Manual mocking has always been, if not a pain, a major annoyance.

On a side note, I got a good chuckle from the "Bobby Tables" XKCD reference[1] in the Jest tutorial[2].

[1]: http://xkcd.com/327/ [2]: http://facebook.github.io/jest/docs/tutorial.html

Not to distract from the topic, but jlongster's posts should be a case study into how to make an effective demo/tutorial on the web. The side by side code/demo format is very well done and should be the de facto way to do code + demo. There have been so many times when I've been reading a tutorial and click on a demo link that opens a new tab. This makes me completely lose context as I switch back and forth between the tutorial and various demo links.

For another example of a post that takes advantage of the dynamic nature of the web page, check out jlongster's sweet.js tutorial[1]. It's a tutorial on writing macros with JS that you can actually interact with (you can make modifications to the example code snippets and see your macros expand on the fly). Very cool.

[1]: http://jlongster.com/Writing-Your-First-Sweet.js-Macro

This. To my knowledge, JS perf isn't an issue in any modern browser (even the crippled iOS webview). Improving the performance of DOM access and manipulation (not just on iOS) would be a much more fruitful enterprise and is something I would like to see all browser makers focusing on.

The interactive macro editor is a great touch. I don't know if this is prevalent, but this is the first time I've seen a tutorial interactively modify code in the editor for you. Instead of "here, type this into the editor above and see what happens," there will be a link to "click here to see what happens" and it will change the code in the editor accordingly. I think this is a good thing, because I rarely go and do the things that tutorials suggest I do, even if they are as simple as typing into an editor that is 2 inches above the text I am reading.

Absolutely.

Go. Read. This. Book. Now.

This is a must-read for any developer who wants to know Javascript better. This is the book that taught me everything I know about prototypes, method decorators, and functional programming in Javascript. Sure, I'd read countless other Javascript books, but Reg has a way of explaining things in a way that connected the dots for me. This is probably the only programming book I've re-read cover to cover a dozen times or more.

I'd also strongly suggest you throw a few bucks Reg's way for the ebook (PDF, EPUB, MOBI) version of this book. I only know Reg through his writing, but he sounds like a great guy. The fact that he's releasing this gem for free is pure madness on his part.

If you couldn't yet tell, highly recommended.

Good overview of jQuery Deferred and how to use promises (at least the jQuery flavor). Promises (or futures) are a simple concept: an object-level abstraction of a non-blocking call, but they're very powerful when you see them in action. For example, the $.when method:

Let's say you have 3 ajax calls going in parallel. With $.when, you can attach callbacks to arbitrary groupings of those ajax calls (callback1 runs when ajax1 and ajax2 are done, but callback2 runs when ajax1 and ajax3 are done).

I first learned about promises in Trevor Burnham's excellent book Async Javascript (http://pragprog.com/book/tbajs/async-javascript) and it is still the best explanation of promises I've ever read. If you like this article and are interested in reading further about promises or the asynchronous nature of Javascript in general (both for browser and node.js), I highly recommend you check out this book.

Love it. This is a great read on the evolution of a design and what goes through a designer's head as they're iterating on a concept. One thing that should particularly stand out is that the format of the article is a continuous loop of 1) Design problem followed by 2) How I solved the problem. This is how great designs are made: constant iteration.

What is more interesting to me is that it seems like one of the key things to generating this loop is identifying design problems. If you can't really pinpoint what is wrong with a design, how can you make it better? Here, Ian seems to get a lot of feedback from other people, but I'm curious as to what kinds of internal thought processes he has when trying to identify exactly where a particular design is lacking.

One heuristic that works for me is thinking about the context of a design. In other words, how did the user get to this particular screen? What are their intentions when entering this view? Almost no individual UI element is self-explanatory when it's devoid of context. Just thinking about what the user wants to do at this particular part of your UI flow can help identify ways in which you can make the design clearer and more in line with their intentions.

In any case, there are a ton of great design patterns to pick up from seeing how Ian thinks about problems. Every designer needs to read this.

A lot of great information here. I always knew that overqualifying selectors was bad, but it was always from a "clean code" point of view and not so much from a performance standpoint. Even more reason to avoid them now.

Although this is very interesting information, anyone reading this article should pay careful attention to the ending headline, "Is all this really necessary?" Odds are, unless you've produced some kind of CSS monstrosity, your CSS isn't the bottleneck in your website performance. Min and concat your Javascript, use appcache, local storage, etc. before prioritizing CSS performance.

For a practical (but involved) overview, there's this: http://webtypography.net/toc/

It's a classic typography book translated to a web context with the relevant CSS styles. Pretty cool.

For a more easily digestible (and interactive!) overview, the one that comes to mind is the Interactive Guide to Blog Typography: http://www.kaikkonendesign.fi/typography/

If you'd like to check out more resources, hackdesign, a newsletter of curated design-related links, is focusing on typography this month: http://hackdesign.org/courses/

This seems like a great starting point for anyone who is interested in designing a website with a strong emphasis on text content (think blogs, online magazines, etc). If you've ever tried to formally study typography, it can be pretty overwhelming. I'm a web developer with an interest in design, and type is one of those things that seems simple until you realize you have to understand it intimately at multiple abstraction levels (individual letterforms, lines, and blocks of text). Glad to see there's a resource out there that uses typography best practices and makes them sensible defaults.

I was also confused by this line. Thick blocks of color appear darker than thin blocks, so a heading would need to be slightly lighter in order to appear the same color as the body copy.

One of the areas where Trello really excels is representing agile workflows, as evidenced by the many organizations that use Trello for internal organization. That said, I think Trello's biggest strength is the huge amount of flexibility you get to develop and experiment with a system of organization that you're comfortable with.

You probably wouldn't guess this just from a glance at Trello's UI, which is surprisingly clean and uncluttered. At its core, it's just a bunch of cards on a board (and you can use it as such), but as this article mentions, you can pull in more powerful features like checklists and labels to represent almost any workflow you can think of. It's a surprisingly powerful, modular system.

Personally, I found this a breath of fresh air from the modal-based alert dialogs out there, although I wouldn't call it an alert per se. Alerts (as others have mentioned) block the UI and prevent the user from interacting with it until the message has been dismissed. This is more of a low-key notification element.

First of all, I'm not crazy about the other themes, but Future (the one enabled by default in the demo) is gorgeous. Maybe I'm just a fan of circular progress bars, but check out the demo involving "Error destroying alien planet." This is really pretty!

The stated use case for this is "transactional messages in your app." For that I think it fits pretty well. It might work as a debugging utility, similar to how we used alert() before we had console.log(), but it seems like the intended use case is for an end-user-facing interface.

Two minor gripes: 1) Backbone as a dependency for a UI element is kind of overkill. 2) This is more of a pet peeve, but why is the demo written in Coffeescript? I love Coffeescript and use it all the time, but I think it makes more sense for something like this to be demoed in Javascript. People who know Coffeescript are a subset of people who know Javascript, so you cater to a larger demographic this way.

That out of the way, great job on this. I'll have to find a project to use this in :)

Hi, I'm a (fellow) cofounder at Tabule.

You make a lot of valid points. As guptaneil alluded to, the ideal case would be if we could get teachers to post their assignments on Tabule. Teachers for the most part already post assignments online, but the education market lacks a good central homework management system that aggregates assignments between classes.

What we're trying to achieve is to bridge to that ideal case with student-submitted assignments. There's an interesting dynamic at play here, because inputting all of one's assignments is trivially better (perhaps even worse if we consider switching cost) than using Google Calendar. For the second person to join the course though, the experience is already better, because all of their assignments are already available to them. It's an interesting chicken-and-egg problem. If my assignments aren't already in the system, then there's no immediate value for me, but there will be for everyone that comes after me.