vinodkd

+1 to the switch gh-pages comment.

Typically 'master' is where the code is and 'gh-pages' is where the pretty docs are. In your case everything is in gh-pages. Either maintain the code in master and "deploy & display" it on the gh-pages branch or just make gh-pages your master.

come to think of it, that's what i should do with some of my repos ;)

Actually, i'd like to use it to disconnect the last piece of blogging software from the server - comments.

the recent post on jekyllbootstrap.com had instructions on connecting to disqus,quora etc and I couldnt help but think:

"but that's just more text, why are we sending people away to a 3rd party for them to just comment?"

A jekyll addon that handles comments using this library, anyone?

every time I see such a project show up I'm both happy and sad: happy to see one more soul arrive at the "there must be something better than text" thought and doing something about it; sad because they invariably create a visual/structural editor.

... and not a really good one, at that. Not to pick on this specific one, but if you're creating a UI for code editing that's not text, please design your interaction well. And yes, I know that this is probably version 0.1 and you plan to smoothen the rough edges, which is why i'll not pick on the fact that the editor for each structural element is not even in-place, for example. </end snarkiness>

but that's not my point. writing code as text conflates two things (or 4, depending on how you think of duals):

1. source text has both syntax and meaning.

2. source text is both the display and storage format (this is the killer feature/bug).

my point is that every attempt to "solve" the "problem of coding using text" (on in this case the subset of lisp's umpteen parens getting in the way of understanding) focuses on the first half of #1 above.

as others have mentioned, there have been structural editors since the 80s. from the research i did (admittedly with limited acm access) they seemed to have died down due to two problems:

1. the scale problem: text packs the largest amount of information into the smallest amount of space. any visual/structural system better have a good way of dealing with large codebases.

2. the fluid use problem: it looks good, but is it easy to use when editing anything but a small enough piece of code this way? typically the amount of interaction "work" you have to do to jump between elements and so forth makes it very inefficient compared to text. the commonly cited example was "How do you change a for loop to a while?". in any text editor, you can take the characters apart easily to reform them into some other construct, but in a structural editor, you have to actually delete all or most of the old structure and re-form the new one. i did find research that refuted this specific claim (ask if interested), but that didn't help the adoption.

i have been thinking of "better ways to code" and structural editors in particular for about 3 years now and here're some of my conclusions to date:

1. text is king because of its universality - think cypher from the matrix saying "I don't even see the code. All I see is blonde, brunette, red-head"

2. We already have good structural editors. They're called vim and emacs. vim has the better interaction model, imo, while emacs has better support for creating new language modes (again, imho, no flame war intended). then there's the smalltalk ides that inspired the Visual Age products that inspired eclipse.

3. The additional overload of "chrome" in text the {}'s, ()'s and begin/ends are much less a hassle than that caused by a visual editor's chrome.

4. There is much more value in pursuing better ways of coding than just flogging the "text sucks" meme. Think Non-textual language workbenches, for example.

Finally, one specific commment about playing around with lisp's syntax. I've tried it (https://github.com/vinodkd/lispdown) and the one thing that stands out is: Lisp has no syntax, so it can become any syntax. I dont know how any structural editor can handle that in a meaningful way.

if you really want to get serious, you probably have to change the page name that your blogging software generated for you as well - cos its pretty prominently being "racist slur"-y on the browser address bar!

See how this quickly gets out of hand? i guess you'll have to delete the post, repost it with a nice clean title and then submit it to the HN firehose all nice and sanitized.

or you could just let common sense prevail.

nice article, btw.

FWIW, here're some details about the company:

1. It seems to be run from Kolkata (capital of West Bengal): Goto maps.google.co.in and search for Comantra. The result has a phone number you can call

2. They seem to be hosted by GoDaddy. Does anyone want another go at that angle? Although, knowing GD this is the kind of customer they want!

3. Linked in also returns somebody who calls himself Owner of GoMantra. Not linking here for obvious reasons of mistaken identity.

IANAL, and I couldn't find a resource that I could point you to from an indian legal POV. Cybercrime has only recently been defined by indian law and from all that I read (not much authoritative) there's not much in this area. Any law-savvy indian HNers care to chime in?

Random browsing of questions led to this one: http://mycareerstack.com/question/120/

...where the following advice is given: "But your strategy while answering this question should not be directly this answer. Generally in the interview you should start with the worst answer and then improve upon it.

If you directly give this answer then the interviewer would know that you had done this question before and may not give credit to you for the answer."

Hmm....

Sound advice, but there's something morally off, IMO.

Do you hate the player or the game, I wonder? Or the online site that helps the player play the game?

As others have commented, interviewing is broken.

I once interviewed for an architect position for one of the "web scale" companies and it was a algo fest all through. All the while I remembered the dev manager (whom I'd have reported to) saying that they were looking for an architect for a new project and the key challenge was learning all the existing components they have, picking the right ones for the job (or proposing to build new ones as required) and then - most importantly - getting it sold to a bevy of other architects and stakeholders.

This was right up my alley as I currently lead 3 teams and we regularly have to deal with architecture and design issues on a large application with tons of other teams involved; and I was therefore pretty stoked about the job -except that the algorithm wall stood between me and it. Not having ever done an algorithms course formally(although I read the books out of interest) I went down in flames; at least I think I did - because I'm yet to hear from them. Wanting closure I even contacted them and asked point blank if I was rejected, but I was assured that I WASNT rejected and that they'd "get back to me".

The process itself was largely the standard "how would you write <algo x> in java", which I did not do very well. One interviewer asked me to implement a Queue using two stacks and maintained that "there's a better way" despite my multiple attempts. I finally asked him if this was an actual real world problem that they faced in their company to which his answer was a glib "No, I was just testing your problem solving ability"

To be fair, however, some of the other interviewers were better.

One actually glanced through my resume, picked on one of my open source projects and grilled me on what I'd do given a hypothetical implementation constraint on a particular piece of the architecture. In hind sight it looked like he was trying to get at my algorithmic problem solving ability while connecting to something I'd built; but at that moment I was so hung up on the problem that that my software solved than how the software itself was built that I ended up frustrating him with my pre-thought solutions. He kept asking for "from scratch" solutions to which most of my responses were "but it already exists in X, so I'll just use it".

The best interviewer was a senior guy who was totally OK with my lack of algo knowledge; and very quickly switched to designing a solution to a web scale problem. He asked me for one solution, picked out the flaws in the solution using Big-O notation and asked me to refine it. This went on until we reached the asymptote that they had actually implemented in production. Along the way, he gave me more of the solution than I did to him, but I ended up with a better appreciation of the whys and wherefores of the problem; and more importantly, problems of the kind.

My general take away was that companies that use algorithm tests make the following assumption:

        algorithm solving ability => general problem solving ability

...and this is obviously true for companies where scale is a fundamental issue, ie , where the scale of the problem has not been addressed by any existing solution.

However, the problem with using this definition to measure candidates are:

1. Your company problems may be solvable using existing solutions. Then the real litmus test for your candidates is how well he can assess and assemble existing components/frameworks/libraries to realize the solution. This is where attitude matters more than anything else; as does prior work and interest in such work. "What was the best project in your career and why" might be the best question to ask such a candidate.

2. Your interviewers may never connected the LHS of this equation to the RHS. This is where, IMO, questions like "queue using 2 stacks" or "manhole covers being round" come. The interview becomes cargo-cult worship at the Algorithm/Puzzle altar.

So my suggestion to the companies that still have algorithm-based interview processes is: when presenting such a problem in an interview at least tie it to a real-world scenario that you had to deal with in your work place so its not a test of how much practice I've had with Cormen and Skiena (yup read the yegge post).

Speaking of which: Am I the only one who finds all algorithm books as being too prescriptive? They all seem to dwell on the laundry list of data structures followed by the laundry list of algorithms; leaving the reader to figure out the "what to use for what" and the "why" all by himself? I'd pay for an algorithms book in the style of Polya's "How to solve it". Skiena's war stories are an attempt in that direction, but a full frontal attack on A&DS would be great.

Aftermath: I left that interview with two takeaways:

1) I had to shore up my knowledge of algorithms and data structures simply because it was the "basic tools of the trade" and there ARE still problems around that need you to dig that deep in the industry (thanks to the final interviewer)

2) Large organizations have "how to assemble software using existing pieces" issues in their software development, not "build from scratch" issues; but developer(turned interviewer) hubris will always skew towards testing for the ability to build (proxied by algorithm skills).

Either way - 37 signals notwithstanding - it makes sense to catch up on your algo skills :)

Oh, and please, please, please lets do away with the Hollywood principle when it comes to developer job rejections. If I'm rejected, tell me. I can take it.

but what about dryad?

This is my biggest peeve with Google as well. I can live with the back button being remapped, but taking over the arrow keys are an absolute nightmare. I refuse to disable javascript because google think they know what should happen when I hit the arrow keys.

A close second: Not mapping forward slash for "search in page" in chrome. This is the single most requested feature in chrome that the devs refuse to implement (see issues 90 and 150 on the chromium projects bug tracker).

How is this HN-worthy?

As an Indian, I'm deeply interested in what's happening here right now, but I fail to see how this is useful in this forum.

Seems like an interesting stab at fixing the drudgery that web app development has become. Some questions, however:

1. When you go through the pains of integrating everything else, why not go for gold and exclude x/html and css as well? These are as "glue, antagonistic" as the other bits that make up the current webapp quagmire.

2. When ideas like PaaS are emerging, wouldnt it be better to bundle everything that makes up the app separate from everything that makes up the platform? I know that this sounds like the antithesis of your "one executable" idea - and I love single executables where appropriate - but it seems like webapp deployment could do with some economies of scale on the underlying container in the sense that the difference between App A and App B is primarily in the functionality, not in the way those functions are accessed, used, etc.

Great article.

I had to comment on this bit, tho:

"ordered sandwich platters from Costco"

Nice to see the White house doesn't splurge willy-nilly :))

The key difference, IMO, is that true agile doesn't require overt project management or more importantly, project managers. the usual response to the "wining battles, losing war" is to introduce someone who's keeping track. unless that someone is "everyone on the team", you tend to move away from agile because:

a)its not everyone's problem, so its not going to be fixed, or

b)the pm guy becomes the fountain head of knowledge from the pmbok that guide the "one true way"

Not to take all the good points away from this article, but I found these two statements contradictory:

1. If you do have a fixed time, then scope is variable

2. If you have to give a fixed date for delivery - it's very, very difficult to be agile.

I've found that #2 is possible as long as you allow for #1. When you have a deadline, you actually become more agile - decisions on what should and shouldn't be done are quicker and the cut off line between "must have"s and "nice to have"s is more obvious - simply because decisions have to be made. Think of moving out of an apartment: are you surprised how productive you get in those last few days?

I have also see misuse of #2: teams take #2 as carte blanche to hold the business at ransom to the "it'll be done when its done" mantra.

It almost seems like there's three kinds of agile nowadays:

1. Big A - the agile that the manifesto became for whatever reasons

2. Small a - the agile that the purists conjure up in reaction to Big A

3. Reality - where when it happens, you can look at each other and say "We were really agile right there - and shipped something right!"

I am a long time lurker on hn, and like mzl, dont care about karma at all.

reading the ~160 comments on the topic, however, sounds weird to me because being indian, karma is not just a number against your online profile, but a fact of life - a word that you hear from people several times during a normal day - and they've probably never even been online.

i get that its about measuring the overall place of a person in a community, and that "karma" is as good a tag as any to condense that concept into one word, but it just seems very weird when there's so much debate around it. true karma is not exactly the "double-entry book keeping of life", nor does it have a leaderboard (which, btw, i realized existed on hn only recently).

on hn, the linked content's mostly great and its always useful to check the comments before loading up the link itself. that should be enough, imo.

ps: yes, i feel the same way watching "my name is earl", although i do enjoy the show itself.

it looks like you could use most any text editor. most os's have a default text editor.

if you want a ruby IDE, try redcar - http://www.redcareditor.com.

From the server to the client these are the things wave is/was:

1. server: the ability for you and me (or equally easily your company and mine) to run our own exchange servers

2. client: the ability have true threaded conversations - not crude conventions that denote conversations, which could at any point be converted into finished documents

3. client: the ability to include new participants into the conversation while allowing them to actually see the progression of the conversation before they joined.

4. client: the ability to have an arbitrary amount of open automation at every point of the message's lifecycle. emphasis on open because anybody could write an automaton (robot, agent) to automate things - not just google.

there're more but that list in and of itself is a few orders of magnitude better than the current state-of-the-art for email.

What it has, but neednt:

1. the update as you type feature. it is still cool, but really not required for everything else that wave is.

2. the unnecessary digressions from standard web technology. why did we have to have a huge public discourse on a scroll bar, for eg?

What it should have had, but didnt:

1. a way to bridge current email into wave. This was the single most important thing google should have done - allow people in email land to send you an email that would show up as a "dumb" wave, and have the ability to send out email updates to such people with the full snapshot of the wave as the response. yes, its dumb again, but we're used to "reply all with inline comments".

2. artificial scarcity on access to wave. worked for gmail because you could taunt others by sending them emails. not so much with wave.

Yes, this does look like an appjet clone. Not to take anything away from this implementation, however, because it looks like the author didnt know of appjet.

Appjet had the same concept: server side js based on rhino, persistent js object store, etc.The concept, however, was a little bit rudimentary: one app consisted of one js "file". You had to write every possible interaction as functions within that file. It did have an interesting function call based templating mechanism, however, something like so:

  print(DIV(
    FORM({action:"/", method:"get"},
      SPAN({style: "float: left;"}, "Show"),
        INPUT( {name: "count", value: count, size: "2", className: "in_box"} ),
      SPAN({style: "float: left;"}, "items"),
        INPUT( {value: "Go", className: "in_box", size: "1", type: "submit"} ),
      DIV({style: "clear: both;"})
    )
  ));

Appjet the company had made the source available for download a while ago, and it seems like these folks have run with it:http://apps.jgate.de/

patrick farley is a genius - both in terms of story telling and animation technique. i'm one of those who's been waiting for electric sheep to return. good to see it back!

Please go to the home page and check out his other stories - especially Shapeshifter (which is not back online yet, but you can find some fan-uploaded versions online - http://e-sheep.sansara.net.ua/www.e-sheep.com/shapeshifter/i...).

See http://webcomicsreview.com/examiner/issue041213/farley.html for a good critique of farley's work.

That said, I dont see why this is HN-worthy.