(Disclaimer: I work on Google Cloud Functions)

With Google Cloud Functions, you can run your function locally using the Function Framework libraries (available in all Cloud Function languages) [0]. These libraries are used in production Cloud Functions, so you're not emulating the runtime. The feedback loop / devX is pretty simple with just 1 command to run the function locally like a library for every language.

We have some guides on local development here [1]. Our samples have system tests that use the FF.

You also can bundle your function in a container after building it with `pack build` [2]. This provides an exact container environment with things like environment variables and system packages.

We're working on improving eventing devX, but we have some `curl` examples here [3]. Connecting multiple functions together eloquently is still something to be desired though.

[0] https://github.com/GoogleCloudPlatform/functions-framework [1] https://cloud.google.com/functions/docs/running/overview [2] https://cloud.google.com/functions/docs/building/pack [3] https://cloud.google.com/functions/docs/running/calling

She did say live plants are very important.

(Disclaimer: I work on G Suite Open Source) I open sourced our developer samples this week: github.com/gsuitedevs

There's an increasing amount of things you can do with G Suite, almost all our products have APIs and Apps Script libraries.

If there's something missing in our APIs, feel free to let us know.

Microsoft Office has plenty of COM and VBScript APIs as well. It has really nothing to do with the product being open source.

Not sure what your point is here.

Almost every single company I've ever seen for 20+ years has open sourced their developer SDK examples. It literally makes no sense what so ever to do anything else.

This has nothing to do with what the OP was talking about which is open sourcing the core app.

The comment was about trending G Suite into open source.

You've got to start somewhere. It starts with developer samples, moves into tools, languages (Apps Script), then sub-products.

If you're asking for Google to open source it's products in one big blow, I don't think that will happen without smaller steps. I'm on the team that would probably best start the conversation of considering G Suite in open source. Would love to hear proposals.

I'd be truly excited if Google was prepared to state it had any intention to open source it's actual web apps. But everything I know about the company says that isn't even an option. What you open source is the same as most of the other things Google open sources: The things that funnel you into Google's proprietary services.

Even suggesting that Google Docs, Sheets, and Slides might be open source someday is as unbelievable as suggesting Google's considering open sourcing their search algorithm. But I'd love to be proven wrong.

You are reflecting very poorly on your employer because you are proving that they hired someone naive enough to think that he could try to open source G Suite.

I built a very similar project for classical music using Theano and MusicXML for a Sound Capstone Project at UW.

Blogpost + music: https://medium.com/@granttimmerman/algo-rhythm-music-composi...

GitHub: https://github.com/grant/algo-rhythm

That's a lot of `padding-top`. Almost looks like the vertical height is misaligned.

In Seattle, Stash (https://angel.co/stash-4) is doing this.

I created a music auto-player since I was too lazy to play your guy's songs by myself. Paste this in the console.

  // SETTINGS
  var input = "rsa ecde srgu yhgr bv rsa ecde srgu yhgr bv hybtg ser erv";
  input += " hybtg iii r hybtg ser erv tvr rrr rvgres rrr rvg rrr rvgres ";
  input += "ggg rgh grs sxebbe cuuuhbgres grs sxebbe cbbbgvrsai";
  var TIME_INTERVAL = 300;

  // Add jquery
  var script = document.createElement('script');
  script.src = 'http://code.jquery.com/jquery-1.11.0.min.js';
  script.type = 'text/javascript';
  document.getElementsByTagName('head')[0].appendChild(script);

  function play () {
    // Sound array setup
    var soundArray = [];
    var down = $.Event("keydown");
    var up = $.Event("keyup");
    input = '  ' + input; // hack
    for (var i = 0; i < input.length; ++i) {
      soundArray.push(input.toUpperCase().charCodeAt(i));
    }

    // Start sound
    var index = 0;
    function playSound () {
      up.which = soundArray[index];
      $("body").trigger(up);
      ++index;

      down.which = soundArray[index];
      $("body").trigger(down);
      // // is there another?
      if (index < soundArray.length) {
        setTimeout(playSound, TIME_INTERVAL);
      }
    }
    playSound();
  }

  (function loadjQuery () {
    if (typeof jQuery === 'undefined') {
      setTimeout(loadjQuery, 100);
    } else {
      play();
    }
  })();

Huh, this doesn't seem to handle commas or semicolons at all. I can't immediately see why, since string.toUpperCase() maps "," to "," and ";" to ";", as it should. And switching input to

"uyvyu,pl,ynuuupl,kmk,,uyvuyvyu,pl,ynuuupl,kmk,,uyvppp;[[;plp;;;pl,kmk,ynuu,,,kmmml;pl,,kuu,lp;[,lp;l,"

completely breaks it about half way through.

Anyway, cool hack!

That's because the keydown event uses keyCode instead of charCode, and the two don't always match. Try typing Shift+U and then '[' on this page to see what I mean: http://unixpapa.com/js/testkey.html.

Since KeyboardJS is already loaded via requirejs, we can require it and then use it to get the keyCode for each character in the for loop.

    var KeyboardJS = require('lib/keyboard');

    [...]

    for (var i = 0; i < input.length; ++i) {
      var code = KeyboardJS.key.code(input.charAt(i));
      if (code) {
        soundArray.push(code);
      } else {
        soundArray.push(32);
      }
    }

Here's an updated version of the script, using your example as input: https://gist.github.com/peterjmag/489364ca58330c348c33

I particularly like input = "qwdtytdwqertytreqxctntcxzxctbtvwqwdtytdwqertytreqxctntcxzxctbtvwqwdtytdwqertytreqxctntcxzxctbtvwqwdtytdwqertytreqxctntcxzxctbtvwqwdtytdwqertytreqxctntcxzxctbtvw"

It's a me, Mario.

For anybody who wants a little bit more structure than LCON but less clutter than JSON, I'd recommend checking out CSON.

https://github.com/bevry/cson

There's a few really awkward corner cases that are much clearer in YAML (and, it seems, LCON). The most significant one, to me, is lists of objects, which are perhaps not so common in code literals (hence why people don't tend to run into it in coffeescript), but do tend to come up a lot in structured documents. In JSON they are trivial:

    [
      {
        "a": "b",
        "c": "d"
      },
      {
        "e": "f",
        "g": "h"
      },
    ]

In YAML also trivial and very concise:

    - a: b
      c: d
    - e: f
      g: h

But in CSON (if I remember correctly), I think this looks odd and confusing by comparison:

    [
      a: "b"
      c: "d"
    , # <- note dedent, without this it comes out as one object not two
      e: "f"
      g: "h"
    ]

Now, in each of these you can just revert back to JSON for the difficult part, but that kind of defeats the purpose. I think YAML-the-syntax strikes a really nice balance between eliminating unnecessary punctuation and having solid structure, and LCON seems like it does as well. CSON errs too far on removing punctuation without a lot of thought put into the remaining structure.

If I understand correctly, the above example in LCON would be (at most minimal):

    . a b
      c d
    . e f
      g h

I actually really dislike this use of . and would like to know a rationale for it, to be honest.

This was one of the reasons I designed it the way I did; I think it's a nice middle ground between YAML and CSON.

As for the ., I chose it over - or * for the bullet character because I designed LCON as the syntax for a JSON-Lisp programming language, and - or * could conceivably be used as prefix operators for math functions (* [5, 6]), leaving . as the only "bullet-like" ASCII character left.

The more I write LCON, the more I realize that the . can be difficult to see (though it's still not as bad as CSON's dedented commas...), so I can see your point, I'm just not sure what other character to use. In an earlier version, I had used :: as a bullet, but that ended up looking ugly.

If I was working in a language that used isomorphic json-like, I think I'd expect it to have call signatures more like smalltalk (object verb subject) than lisp (verb object), so calling '-' or '*' would seem strange to me.

But I don't know anything about this other project of yours other than what you've said here.

I'd say just use hyphens like YAML, but I guess I get the keyspace-advantage of using a dot. Still an aggravating change.

This project was partially a response to CSON. CSON was almost (but not quite) good enough for my purposes, so I made something that was.

I love being able to drive in reverse at 300km/h.

This is a feature of Big Rigs, the "Best game ever."

http://youtu.be/sVREUuuNIgg

Technically there's no upper bound on the reverse speed in that game. A curious decision.

"decision", heh!

Obviously that it's a decision! :D Think that it's a tribute to Big Rigs... Hehehe...

Fun stuff.

  function action(){
    var opacity1 = $('#color-1')[0].getContext('2d').getImageData(0,0,1,1).data[3];
    var opacity2 = $('#color-2')[0].getContext('2d').getImageData(0,0,1,1).data[3];
    if(opacity1 > opacity2){
      $('#color-1').trigger('click');
    }else{
      $('#color-2').trigger('click');
    } 
  };

  setInterval('action()', 100);

I think the game has been updated, now the opacity of both colors are the same (255) but you can sum R, G and B parts. The highest will be the brightest.

function c(i,j){return $("#color-"+i)[0].getContext('2d').getImageData(0,0,1,1).data[j]} setInterval(function(){$("#color-"+(1+(c(1,0)+c(1,1)+c(1,2)<c(2,0)+c(2,1)+c(2,2)))).click()},1)