Humanist → Blog by Luke Hoersten https://www.humani.st Computer Science, Business, Blogging, and Technology Blog by Luke Hoersten Thu, 05 Jul 2012 21:07:09 +0000 en-US hourly 1 http://wordpress.org/?v=3.4.2 http://creativecommons.org/licenses/by-nc-sa/3.0/Subscribe with BloglinesSubscribe with Google Jawbone UP: Not Ready for Christmas http://feedproxy.google.com/~r/Humanist/~3/zaKFpHu4QZM/ https://www.humani.st/jawbone-up-not-ready-for-christmas/#comments Sat, 03 Dec 2011 03:26:13 +0000 Luke Hoersten https://www.humani.st/?p=432 Jawbone makes a device called UP which tracks your movement while you sleep and move around during the day through a wristband. Below is their order form where I’ve highlighted the relevant information I was trying to ask their customer service about. I simply wanted to know if the “coming soon” colors would be available for Christmas:

 

The customer service interaction follows as:

Customer By Web Form  - 12/01/2011 07:06 AM
Will the alternate Up colors be available in time for Christmas?

Thanks,
Luke

Response Via Email(Sean) – 12/01/2011 10:37 AM
Hi Luke,
As we are looking forward to the release of all the colors of UP bands, there is no ETA for when they will become available. We ask that you please just watch the website as they may come available at anytime. Thanks for contacting Jawbone customer support.

Sincerely,
Sean

Customer By Email  - 12/01/2011 07:58 PM
Christmas is in less than a month. If it takes one to two weeks to ship,
you must know if the alternate colors will be ready by next week… Since
you said I should “watch the website as they may come available at
anytime”, this seems to imply an impending release.

Should I wait to buy alternate colors for Chrismas or not?
- Luke

Response Via Email(Sean) – 12/01/2011 08:05 PM
Hi Luke,
I checked with my supervisor and he said that if you place an order now you should receive it by christmas.

Sincerely,
Sean

Customer By Email  - 12/01/2011 08:14 PM
Great. How can I select the color I’d like on the purchase website?

- Luke

Response Via Email(Sean) – 12/02/2011 01:21 PM
Hey Luke,
Unfortunately you are not able to place an order for a colored band at the moment, but please keep checking our website as the option may become available at any time.
Sorry for the inconvenience but I hope this answers your question.

Sincerely,
Sean

Customer By Email  - 12/02/2011 03:28 PM
No, Sean, you still have not answered my very simple question:
Will I be able to order alternatively colored bands for Christmas.
“Check the website because it might change at any time” does not answer
that question.
- Luke

Response Via Email(Sean) – 12/02/2011 03:37 PM
Hi Luke,
The official status on colored bands is that we fully intended on making them available.
However there has not been a scheduled released date. Sorry if this is vague  but this is the only information that is available.

Sincerely,
Sean

This leaves me with two possibilities:

  1. I buy the black band and then they end up releasing the colored bands in time for Christmas
  2. I wait as suggested, eagerly checking the website every day, and the colored bands never come, leaving me with no gifts.
Update: Looks like the reason they’ve been so flaky answering questions about availability is because Jawbone was planning a big buy-back plan for all the faulty bands (apparently quite a few) that had made it out into the market.
Similar Posts:
    None Found
]]>
https://www.humani.st/jawbone-up-not-ready-for-christmas/feed/ 2 https://www.humani.st/jawbone-up-not-ready-for-christmas/
Google Friend Connect: Deface Your Site http://feedproxy.google.com/~r/Humanist/~3/aDuX0MmrAaE/ https://www.humani.st/google-friend-connect-deface-your-site/#comments Wed, 17 Dec 2008 06:00:43 +0000 Luke Hoersten https://www.humani.st/?p=404 After adding a few Google Friend Connect widgets to my site, I’ve determined that relationship just wont work out. GFC looks like trash. All the widgets must be pre-formatted to a specific pixel width and height. I’ve spent hours searching for this theme, tweaking it, crafting everything to the em, and making sure everything integrates perfectly. Imagine spending hours baking the perfect multi-layer wedding cake and then at the end, scribbling the name of the bride and groom on a few sticky notes and slapping them on the frosted flowers. Sure, value is being added, but at what cost?Cake

I was a bit afraid that Google had the girth to capture some of the potential mainstream demographic from Disqus but now I realize that Google’s going for the cut-copy-paste website owners. Google used to be so good at design but somehow they’re becoming the web2.0 version of good ol’ 90′s Geocities.

Disqus will soon have more mainstream accessibility with the comming addition of Facebook Connectect. Facebook Connect will achieve the same “value added” as Google— linking Facebook accounts with websites— but with the elegance and tailored integration of Disqus blog connection.

Similar Posts:
    None Found
]]>
https://www.humani.st/google-friend-connect-deface-your-site/feed/ 10 https://www.humani.st/google-friend-connect-deface-your-site/
Talking to Erlang http://feedproxy.google.com/~r/Humanist/~3/huXdMEKs4MA/ https://www.humani.st/talking-to-erlang/#comments Tue, 29 Jul 2008 02:25:54 +0000 Luke Hoersten https://www.humani.st/?p=393 In a previous post, Scalable Web Apps: Erlang + Python, I talked broadly about using HTTP to make external applications talk to an Erlang cluster over the internet or network. The following code is an example of a MochiWeb server set up to receive HTTP requests with embedded JSON. HTTP is basically used as a nice wrapper around whatever data is being sent and data is wrapped-up in a serialized form called JSON. The following goes in the generated MochiWeb skeleton code file called project_name_web.erl:

%% @author Luke Hoersten <Luke@Hoersten.org>
%% @copyright 2008 Luke Hoersten.

%% @doc Web server for example.

-module(example_web).
-author('Luke Hoersten <Luke@Hoersten.org>').

-export([start/1, stop/0, loop/2]).

%% External API
start(Options) ->
    {DocRoot, Options1} = get_option(docroot, Options),
    Loop = fun (Req) -> ?MODULE:loop(Req, DocRoot) end,
    mochiweb_http:start([{name, ?MODULE}, {loop, Loop} | Options1]).

stop() ->
    mochiweb_http:stop(?MODULE).

loop(Req, _) ->
    io:format("~nReceived:~n~p~n", [Req]),
    case {Req:get(method), Req:get_header_value("Content-Type")} of
        {'POST', "application/jsonrequest"} ->
            do_stuff(mochijson2:decode(Req:recv_body())),
            Req:ok("text/plain",
                   [{"User-Agent", "Erlang/example/0.1"}],
                   <<"Processing Request">>)
        _ ->
            Req:not_found()
    end.

%% Internal API
do_stuff(Data) ->
    io:format("~nData: ~p~n", [Data]),
    Nodes = [{'erlang@pod5-1', 4}, {'erlang@pod5-2', 4},
             {'erlang@pod5-3', 4}, {'erlang@pod5-4', 4},
             {'erlang@pod5-5', 4}],
    plists:foreach(fun stuff:do_stuff/1, Data, {nodes, Nodes}).

get_option(Option, Options) ->
    {proplists:get_value(Option, Options), proplists:delete(Option, Options)}.

How it Works

The server is basically a loop which uses MochiWeb to pull HTTP requests out of a TCP/IP socket. If the HTTP header is a JSON HTTP POST, then the JSON is deserialized and applied to the function do_stuff. do_stuff then parallelizes the data over a cluster of Erlang nodes using the plists library for processing which can talk to each other with message passing as needed. The “OK” response is sent back to the application which sent the HTTP request, after the parallelized processing completes, without doing any exception handling.

For reference, here is the example Python from the other end of the connection:

def send_to_erlang(data):
    url = "http://erlang.nodes.tld:8000/"
    body = json.dumps(data)
    headers = {'Content-Type': 'application/jsonrequest',
               'User-Agent'  : 'Python/Project/0.1'}
    urlopen(Request(url, body, headers))

It may seem simple, and it is simple because of Erlang and MochiWeb, but before seeing how this all fits together, it can seem mysterious. Please feel free to comment with questions and I’ll try to clarify as much as possible. Thanks to the MochiWeb mailing list for helping me when I was starting out.

Similar Posts:
    None Found
]]>
https://www.humani.st/talking-to-erlang/feed/ 10 https://www.humani.st/talking-to-erlang/
Why Make Erlang a Functional Language? http://feedproxy.google.com/~r/Humanist/~3/q5PWNInXzF4/ https://www.humani.st/why-make-erlang-a-functional-language/#comments Fri, 27 Jun 2008 02:30:08 +0000 Luke Hoersten https://www.humani.st/?p=381 Why Does Erlang Have Weird Syntax?

I’ve heard the argument many times. People “don’t like Erlang’s syntax so [they] don’t like Erlang.” I, for instance, didn’t understand the block terminator syntax when I was first learning Erlang, so I asked Yariv Sadan about it:

Erlang syntax came from Prolog. The ‘end’ keyword is used to end code blocks that are contained inside the body of a function, and the ‘.’ symbol is used to close top-level function definitions.

Yariv Sadan

But what is the purpose of such a strange syntax? Is Erlang’s syntax really that weird or is it the single-assignment semantics which people don’t like? Erlang’s SAS derives from the functional programming paradigm which begs the real question: “Why is Erlang a functional language?”

The answer in a nutshell: To attain more language features, like message passing in Erlang’s case, the language incurs some overhead so efficiency gains must be made to compensate. It’s the same concept behind data structures: In order to know more about data, semantic restrictions can be imposed. In this case, the data is the program source itself and the imposed restriction is data immutability.

Erlang’s data immutability can be split into two levels: intra-process variable immutability and inter-process data isolation.

Why Doesn’t Erlang Have Share Data?

Concurrency is obviously the justification for Erlang’s isolation memory model, with the alternative being locking to synchronize destructive shared data operations. Lock complexity makes scaling hard because locks aren’t composable and are unassociated with the shared data. If data isolation is enforced between concurrent components (what Erlang calls processes), composibility can be maintained because destructive shared data modifications do not occur. Composability, or building instructions with instructions, is an inherent concept of programming and it’s why sequential programs are desirable.

This example excerpt from an older java.lang.StringBuffer class illustrates a common locking misconception. The author wanted to compose the length and getChars calls into one atomic operation to ensure critical data wouldn’t be modified between them. The author attempted to compose the calls by wrapping them in a synchronized method which locks this, not sb. Unfortunately, another thread could still modify sb in between the calls.

public final class StringBuffer {
  public synchronized StringBuffer append(StringBuffer sb) {
      int len = sb.length();
      ... // other threads may change sb.length(),
      ... // so len does not reflect the length of sb
      sb.getChars(0, len, value, count);
      ...
    }
    public synchronized int length() { ... }
    public synchronized void getChars(...) { ... }
    ...
}

Software transactions and message passing are fundamentally better synchronization abstractions than locks because of, among other things, composibility and accuracy, at the cost of greater overhead. STM can be built from message passing and I consider both to be acceptable replacements for lock based synchronization.

Why Does Erlang Have Data Immutability?

It seems that intra-process data isolation would be enough for a clean synchronization scheme, yet this is not entirely true. The immutable shared data model can be made even more complete when applied at the local sequential data level to achieve even more benefits:

  • Immutability efficiency gains compensate for message passing overhead.

    Immutability of data can, in many cases, lead to execution efficiency in allowing the compiler to make assumptions that are unsafe in an imperative language.

    Wikipedia

    To reiterate what I said earlier, the restriction of data immutability allows the compiler to know more about the program and as a result, regain some efficiency.

  • Immutability simplifies type policies for message passing.

    In Scala, [an OOP language with message passing,] you can send between actors pointers to mutable objects. This is the classic recipe for race conditions, and it leaves you just where you started: having to ensure synchronized access to shared memory.

    Yariv Sadan

    To expand on the type policy issue a bit more, it’s simpler to make all data immutable, both local and shared. This reduces the need for special cases intended to disallow sending pointers, or data structures containing pointers, through message passing. This congruency keeps message passing at the core of Erlang’s semantic focus.

  • Immutability makes Garbage Collection simpler, faster, and soft real-time.

    The generational [Erlang] collector is simpler than in some languages, because there’s no way to have an older generation pointing to data in a younger generation (remember, you can’t destructively modify a list or tuple in Erlang).

    James Hague

    Again, more restrictions means different ways of efficiency gains.

Downsides to Erlang’s Non-destructive Memory Model

Many common algorithms are designed with destructive memory in mind. As a result, Erlang doesn’t have some of the same types of data structures and libraries as imperative languages. This, combined with the confusion of learning a completely new programming paradigm, can be a large deterrent for learning functional languages. But what libraries Erlang lacks is largely made up for by an extensive actor based library platform.

Virtually all “big” Erlang libraries use Erlang’s features concurrency and fault tolerance. In the Erlang ecosystem, you can get web servers, database connection pools, XMPP servers, database servers, all of which use Erlang’s lightweight concurrency, fault tolerance, etc.
Yariv Sadan

Erlang is clearly a domain specific language, focusing on problems that can be solved with parallelism. Erlang’s libraries favor this same domain and Erlang holds its own against even C in the targeted many-thread/process arena. Note: the “thread-ring” test on the last line of the chart:

note the thread-ring test

An Erlang web server was also compared to Apache as another more practical comparison (again, intentionally a problem in Erlang’s domain). “Apache dies at about 4,000 parallel sessions. Yaws is still functioning at over 80,000 parallel connections.” So, Erlang may be hard to use because of its lack of conventional libraries or its different syntax, but as I’ve hopefully shown, the differences were chosen by design with good reason. Erlang is clearly one of the strongest languages in its parallelism domain and after a little over 20 years, is a very mature language.

Similar Posts:
    None Found
]]>
https://www.humani.st/why-make-erlang-a-functional-language/feed/ 34 https://www.humani.st/why-make-erlang-a-functional-language/
Google Health Can Fix U.S. Healthcare http://feedproxy.google.com/~r/Humanist/~3/hzZ_TtuiO8A/ https://www.humani.st/google-health-can-fix-us-healthcare/#comments Tue, 27 May 2008 06:00:10 +0000 Luke Hoersten https://www.humani.st/?p=385 Current Healthcare Situation

Google Health

Healthcare in the U.S. is far from equilibrium, with hyper-inflated costs in response to insane insurance costs. This causes healthcare to be unattainable by most lower class and an increasing number of middle class families. Healthcare should be an inalienable right but people avoid visiting the doctor because to them, the impending financial situation is worse than health risks. Still, the U.S.’s healthcare system is one of the best in the world in terms of quality and speed. The looming threat of being sued helps keep us safe though it’s grown so large from being unchecked that it’s too costly for both parties: the healthcare providers and the patients.

Insurance Issues

A free market is a market in which prices of goods and services are arranged completely by the mutual consent of sellers and buyers. By definition, in a free market environment buyers and sellers do not coerce or mislead each other nor are they coerced by a third party.
Wikipedia

Healthcare is another story. Insurance companies are the “third party” behind both sides, the buyers (patients) and the sellers (healthcare providers), and are not working for the “mutual consent of buyers and sellers.” Furthermore, most healthcare is not actually paid for by the patients directly, but instead by patients’ employers who are, by law, not allowed to know about the employees’ health issues. This dichotomy is what has enabled healthcare costs to grow so wildly out of control.

Google Health’s Fix

Eric Schmidt’s keynote speech at the Healthcare Information and Management Systems Society Conference directly addressed what Google sees as “the problem” with U.S. healthcare and how Google could help fix it. In short, put information in the hands of patients to enable informed buying decisions and to rebuild the “mutual consent.” Currently, when a patient needs a medical procedure, say a surgery, they don’t shop around for the best price. The patient goes where their insurance company tells them; Where the insurance company has business affiliations. So informing patients will theoretically break the “employer/insurance payment” dichotomy, disarming the “third party coercers.”

Other benefits of Google Health are clear from a computer science standpoint. Technically it will serve three purposes:

  • Cloud storage — Let the IT professionals deal with data backup and retrieval instead of local medical staff.
  • Information channel — Directly connect patient information to patients and healthcare provider.
  • Privacy — Take sensitive information out of the clear-text paper world of office workers and into the human-free, automated, and encrypted world of cloud computing.

Privacy Issues

Clearly potential Google Health uses will have privacy concerns regarding Google obtaining access to medical records as well as having records available online. IT specialism in general has some clear benefits over the paper trail world:

  • Reduce human interaction — When paper information is being sent around, it passes though many hands in clear text. Most hands are simply staff members intended to help organize office work and should not have access to the sensitive content. Computerized health record retrieval and storage would minimize and automate the amount of human interaction needed, reducing the amount of human mistakes as well as accidental (or intentional) security leaks. Catch Me If You Can illustrates the 1960s banking industry’s similar situation to today’s healthcare industry. Today, all banking is computerized and online. Paper trail security is a myth. For example, George Clooney recently had his hospital records leaked to the press and something like 27 employees were facing repercussions. There were probably many more people that had seen his records as well.
  • Google already knows everything about us — Between searching and emails, Google knows what its users are thinking. They are data mining experts and easily have the ability to learn about most users’ health issues already. There is no hiding form large corporations and laws are in place to protect against intentional misuse of healthcare information.
  • Breaking into an office is easier than hacking into Google — Hacking requires a much higher level of knowledge and is many times more traceable than breaking into an office. If employers wanted access to medical records, it would be safer for them to stage a break-in physically rather than virtually. Local offices also store records in computers and probably gave access to IT consultants as well. Google Health gives the IT side some accountability.
  • Companies are companies — Whether it’s a hospital or an IT company, it’s still private firms charged with keeping our data private.

The office paper trails will probably be around for quite some time but Google is providing a layer beneath it: secure storage, access, and transfer for medical records. From a technical standpoint, our data only stands to be more secure and the small risk of this being false is worth it for what we stand to gain: The free market that was intended by the private healthcare design. Informing patients means educated and mutual consent on healthcare costs.


Similar Posts:
    None Found
]]>
https://www.humani.st/google-health-can-fix-us-healthcare/feed/ 6 https://www.humani.st/google-health-can-fix-us-healthcare/
Suspicious Design Similarities http://feedproxy.google.com/~r/Humanist/~3/ECQUJREa4mw/ https://www.humani.st/suspicious-design-similarities/#comments Sat, 17 May 2008 02:38:00 +0000 Luke Hoersten https://www.humani.st/?p=382 Luke.Hoersten.org Logo

While reading a design blog about new site designs and typography in early April of 2008, I noticed a site called “Hell Yeah Dude” which bore a strikingly similar title and logo design to my personal web site, Luke.Hoersten.org. In particular, the lighter colored top level domain (.com/.org) in contrast to the darker title text, and the asterisk logo and placement with respect to the title. It turns out the site owner, Patrick Algrim, released the site on April 9th, 2008. I have been using the lighter colored top level domain title style since around December 6th, 2007 and released the asterisk logo around March 31st, 2008. That’s at least nine days before Patrick’s design was released.

Hell Yeah Dude Logo

I don’t mean to suggest that I’m the first to come up with lighter colored TLD with a darker title or the asterisk logo, and perhaps I’m being a bit presumptuous to even suggest that Patrick may have even seen my site, but it seems suspicious the way the two design elements have been used together in a fashion so close to mine. I’m sure it’s just coincidence but I wanted to be clear that I didn’t rip the design from Patrick.

Similar Posts:
    None Found
]]>
https://www.humani.st/suspicious-design-similarities/feed/ 5 https://www.humani.st/suspicious-design-similarities/
Scalable Web Apps: Erlang + Python http://feedproxy.google.com/~r/Humanist/~3/zKt1T-hEFw4/ https://www.humani.st/scalable-web-apps-erlang-python/#comments Tue, 29 Apr 2008 04:25:28 +0000 Luke Hoersten https://www.humani.st/?p=377 Motivation

This post describes how to program scalable web applications with Erlang and Python using computational parallelism. Caching and load balancing are well documented elsewhere and beyond the scope of this post.

Web applications, by nature, span two drastically different programming domains: The high-level web design and development domain and the low-level, high-performance, and distributed domain. Since the internet has provided a bridge between these two domains, it’s now possible to realistically provide high-level user interfaces to high-performance back-end applications.

I prefer to do as much programming in Python and the Django web framework as possible because it’s just so easy. ErlyWeb is an Erlang web framework which should provide similar features to Django, though I’ve never used it. In a web application setting, it’s easy to have too many Apache/Python processes which max out server memory or the CPU. For those tasks, I like Erlang. Erlang has parallelism and distribution primitives, which are arguably more elegant than Python’s concurrency primitives, and has SMP support.

Erlang + Python Communication

It seems like a no-brainier to use domain specific languages to ease development efforts in the corresponding domain but the tricky part is making multiple languages communicate when multiple domains are spanned. MochiMedia is a small company that builds many of their products around Erlang + Python and, after shopping around, I chose to use their method of interfacing between the two languages: HTTP + JSON. The data being sent between the two languages is serialized, sometimes with JSON, and then passed along via HTTP. This has a few benefits. First, since HTTP is being used, my Erlang cluster can be across the internet from my Python front-end server. Second, since I’m using an independent intermediate representation to serialize the data (JSON), any component of the application stack may be swapped out for something completely new.

Here’s how it’s done:

  1. Use MochiWeb to enable the Erlang nodes to communicate over HTTP. The latest version of Erlang and OpenSSL headers are needed to compile MochiWeb.
  2. Create a MochiWeb project skeleton. Since MochiWeb is a framework, a script is provided to help create a web server which uses MochiWeb.
  3. Modify the request handler to understand JSON. The only Erlang that really needs to be modified is in [project name]/src/[project name]_web.erl. This is where the processing code goes (ex: map/reduce).

On the Python side, a simple urllib2.urlopen can be used to build Request objects to send to Erlang. Django comes pre-packaged with SimpleJSON to serialize the body of the HTTP request:

def send_to_erlang(data):
    url = "http://erlang.nodes.tld:8000/"
    body = json.dumps(data)
    headers = {'Content-Type': 'application/jsonrequest',
               'User-Agent'  : 'Python/Project/0.1'}
    urlopen(Request(url, body, headers))

Parallelism

Kevin Smith, of Hypothetical Labs, did a great interview with Bob Ippolito, CTO at MochiMedia, which is a great case study for Erlang + Python. Bob talks in-depth about the engineering tasks the model helps overcome.

Computation tasks which can be executed in parallel are key to utilizing Erlang’s distributed parallelism. A relatively small message with big computations is the desired abstraction. For example, the Django web interface could wrap an Erlang distributed map/reduce implementation. The Erlang book enumerates many different paradigms for Erlang distributed parallelism and for programmers who already have an idea, the plists library takes care of all the distribution automatically. A programmer with at least a little experience in both Erlang and Python should be able to hack their way through to a fully functional and scalable web application from here.

Similar Posts:
    None Found
]]>
https://www.humani.st/scalable-web-apps-erlang-python/feed/ 22 https://www.humani.st/scalable-web-apps-erlang-python/
Erlang Circular Process Communication http://feedproxy.google.com/~r/Humanist/~3/cxG_RywBiPY/ https://www.humani.st/erlang-circular-process-communication/#comments Sat, 12 Apr 2008 20:07:41 +0000 Luke Hoersten http://openradix.org/?p=347 The 1984 Chandy / Misra solution to the dining philosophers problem1 requires philosophers to communicate with each other. In Erlang, one way to do this is to have the philosophers tell the philosopher who sat before them that they are neighbors.

Below is my first Erlang program which sets up the circular communication between processes:

%% Dining Philosophers setup.
%% By Luke Hoersten
%% Public Domain (PD) No Rights Reserved.

%% This is the Chandy / Misra Dining Philosophers Solution and it
%% assumes philosophers can talk to eachother.

-module(dine_phil).
-export([dine/1,sit/1]).

%%%% Setup
dine(Places) -> sit(Places).

%%%% Fork
pickup_fork(Clean) ->
    spawn(fun() -> fork(Clean) end).

fork(IsClean) ->
    receive
        {Phil, is_clean} ->
            Phil ! IsClean,
            fork(IsClean);
        set_dirty -> fork(false);
        set_clean -> fork(true)
    end.

%%%% Sit
sit(Num) -> %% first expects last as left
    First = spawn(fun() -> greet(last, pickup_fork(true)) end),
    sit(Num-1, First, First).

sit(1, Left, First) -> %% last expects first as right
    spawn(fun() -> greet(Left, First, pickup_fork(false)) end);
sit(Num, Left, First) ->
    Current = spawn(fun() -> greet(Left, pickup_fork(false)) end),
    sit(Num-1, Current, First).

%%%% Greet
greet(Left, First, Fork) ->
    First ! {last, self()}, %% last tells first when he's seated
    greet(Left, Fork).

greet(last, Fork) -> %% first waits for his right and last to sit
    receive
        {last, Last} -> greet(Last, Fork)
    end;
greet(Left, Fork) -> %% everyone tells left when he's seated
    Left ! {right, self()},
    receive
        {right, Right} -> eat(Left, Right, Fork)
    end.
  1. In computer science, the dining philosophers problem is an illustrative example of a common computing problem in concurrency. It is a classic multi-process synchronization problem.
    Wikipedia

Similar Posts:
    None Found
]]>
https://www.humani.st/erlang-circular-process-communication/feed/ 8 https://www.humani.st/erlang-circular-process-communication/
Fix Disqus Validation Errors on WordPress http://feedproxy.google.com/~r/Humanist/~3/SNJehF8d6lg/ https://www.humani.st/fix-disqus-validation-errors-on-wordpress/#comments Sat, 12 Apr 2008 19:47:58 +0000 Luke Hoersten https://www.humani.st/?p=373 Disqus is a great comment system but unfortunately the WordPress plugin generates invalid XHTML. Luckily it’s pretty easy to fix. I’ve made the necessary changes and packaged them up. A simple diff will show the minimal amount of changes needed.

Disqus WordPress Plugin — Fixed validation

Similar Posts:
    None Found
]]>
https://www.humani.st/fix-disqus-validation-errors-on-wordpress/feed/ 43 https://www.humani.st/fix-disqus-validation-errors-on-wordpress/
SocialThing vs. FriendFeed http://feedproxy.google.com/~r/Humanist/~3/A3fcwp-ma_U/ https://www.humani.st/socialthing-vs-friendfeed/#comments Sat, 12 Apr 2008 18:48:49 +0000 Luke Hoersten https://www.humani.st/?p=371 With blogs, Tumblr, Twitter, Flickr, Facebook, Pownce, Vimeo etc, it’s hard staying on top of the social web. It’s the ever-cliché problem of “more information that we know what to do with.” The social web, to me, is analogous to CML‘s message passing model. All the modular social apps listed above are communication channels and humans are the actors (the actor model comes full circle ;-D ). Life feeds like SocialThing and FriendFeed are the anonymous send and receive primitives and without them, the social web is nothing more than Java RMI. SocialThing and FriendFeed essentially do the same thing but solve the problem from completely different angles of attack.

FriendFeed

FriendFeed requires all the users friends to also be users of FriendFeed and have added all their feeds to FriendFeed as well. Then, the user must subscribe to all their friends. Since the user has already subscribed to all their friends on all the applications being aggregated anyway, why subscribe again? It’s FriendFeed’s method of filtering. To not hear from certain friends, just don’t add them.

SocialThing

SocialThing social web life feed

SocialThing1, in my opinion, has a much better method of aggregation. The users tells SocialThing about all their web app accounts and SocialThing basically just reads them. So since I already have all my friends added to Twitter, SocialThing will show whatever Twitter would show. FriendFeed would only show my FriendFeed friends I’ve subscribed too who also told FriendFeed about their Twitter. To borrow a bit form set theory, SocialThing starts with the universe and subtracts things out of the friend set (it acutally don’t have that functionality yet). FriendFeed starts with nothing and explicity adds friends to the set.

In my mind, a life feed’s job is to basically act as a join point for sends and receives on my social channels. FriendFeed went and added a whole other later of abstract channels. SocialThing, on the other hand, is much younger than FriendFeed and only has the ability to aggregate a handful of apps. I really need Disqus integration before I can fully use it.

Thanks to Sahil for motivating this post!

  1. I have one SocialThing beta invite left. Comment if you want it. First come, first serve.
Similar Posts:
    None Found
]]>
https://www.humani.st/socialthing-vs-friendfeed/feed/ 13 https://www.humani.st/socialthing-vs-friendfeed/