Disqus - Latest Comments for limulus

Re: What I learnt from coding a text editor in C

Eric McCarthy — Tue, 29 Aug 2017 12:33:46 -0000

My understanding, from my experiences doing both MVC and React/Redux, is that in MVC the controller winds up being responsible for managing mutations of both the view and the model. I've always felt that something was wrong with this, but it wasn't until I got familiar with React that I felt like I could put my finger on it. In React/Redux the controller's dual responsibility is cleanly split: you have a reducer function responsible for mapping events to a new copy of the model state, and a render function that is responsible for mapping the model state into a new copy of the view state. (React takes this new copy of the view state and applies the changes to the view objects that are actually getting displayed to the screen by the browser or OS.) I've found this results in code that has better separation of responsibilities.

Re: Wired’s making the long and slow switch to HTTPS and it wants to help other news sites do the same

Eric McCarthy — Fri, 29 Apr 2016 10:55:02 -0000

One important thing worth knowing is that the browser vendors are moving to push the entire web to HTTPS. Eventually, they will be marking HTTP sites as insecure (for example, a padlock icon with a red slash through it next to the site’s domain name). This more accurately conveys to the user the insecure nature of a network connection with no encryption layer. It also means that sites that do not make a timely move to HTTPS will risk tarnishing their brand with every HTTP page view.

Browser vendors have already started making progress on the road to making HTTP a legacy protocol. In the next handful of months, Chrome is set to no longer support its geographic location API on HTTP pages. If you have a site feature that makes use of this API, there’s already no time to waste.

Re: The Craftsmen Have it Right: Defining Software Quackery

Eric McCarthy — Fri, 28 Mar 2014 13:20:01 -0000

So here's the thing: Homeopaths consider themselves professionals too. They have organizations, conferences and journals where they publish papers. They even have certifications. Their craft has been around for over 200 years and they've developed tons of best practices through shared experience.

Considering all that, can you really be certain that what Software Craftsmanship promotes isn't also quackery?

I'm not saying that's the case. While I don't keep up with the latest goings-on, I know what Software Craftsmanship is, and I haven't gotten the impression that folks are reading and evaluating the studies that have been done or performing controlled experiments to test hypotheses themselves.

If you haven't seen Greg Wilson's talk, "What We Actually Know About Software Development, and Why We Believe It's True", it's worth the hour: http://vimeo.com/9270320

Re: Abstractions: What and When? | Let’s Code JavaScript

Eric McCarthy — Tue, 12 Nov 2013 00:01:16 -0000

In iOS, Apple has something called "Gesture Recognizers". For example, you can add a pinch gesture recognizer to a view, and your controller will receive messages with touch coordinate updates as soon as iOS recognizes that the user is doing a pinch. It seems to me what will eventually be needed here is something like a "drag recognizer". It wouldn't necessarily be something exposed to the client controller code, but something HtmlElement would create behind the scenes when interest is expressed on receiving drag events on an element.

Re: Code Generation Seems Like a Failure of Vision

Eric McCarthy — Wed, 16 Oct 2013 10:19:22 -0000

If I remember correctly, The Pragmatic Programmer talks about the intersection of code generation and DRY. What it comes down to is, if you do a `make clean`, do the generated source files get blown away? If they can be blown away, it passes DRY, otherwise you’ve got a potential problem.

Re: Fast-Forward Git Merge

Eric McCarthy — Fri, 20 Sep 2013 13:43:18 -0000

I don't have enough experience with using git with other people to know if my opinion here has much value, but to me it makes sense for GitHub to not fast-forward. It seems like a good idea to have the ability to identify the merge and the acceptance of the pull request. I'd argue that the problem isn't that GitHub creates a noisy commit history, but that it doesn't provide a way to hide the noise from its visualization of the history.

It seems a lot of people are intent on doing all sorts of cartwheels to keep their commit histories tidy. This has made me somewhat apprehensive about git. However now I'm beginning to suspect that these are all workarounds for not having better history visualization tools.

Re: Discuss tinydb

Eric McCarthy — Sun, 11 May 2008 00:30:11 -0000

I'd suggest making it an option on write, and having the default always output valid XML by encoding the tainted data. (CDATA, perhaps?) The reason being that only the client that does the write really knows whether or not the data is ok to be left unencoded.

So, say something like _xmlsafe=true.

You could take this a step further, and do it with JSON as well. _jsonsafe=true. That way, you can nest JSON too.

Update: On second thought, allowing nested JSON could lead to XSS vulnerabilities for site that use tinydb.org. You might be able to mitigate that risk by running the _jsonsafe=true data through a strict JSON validation, but that might not be worth the effort.