We haven't decided on that yet. We will probably use a WYSIWYG Markdown editor (recommendations welcome!) along with a Git GUI client. That may not work forever, but it should be fine in the medium-term.
Note: marketing folks will probably not be editing the product docs much--the marketing site content is kept in a separate repo so we can provide a different solution there.
KSonnet looks great, but I think it needs to mature a bit more.
PLUS, underneath the hood of Ksonnet is a massive amount of jsonnet code that I'm not extremely familiar with, and I like to learn my tools very thoroughly before I begin using them. So it's a big task to get started with it.
This article is pretty focused on the build type of k8s developer tools. There are other types as well that can fit into specific places in your workflow. Joe Beda does a fantastic high level overview of the different types in last week's #tgik8s: https://www.youtube.com/watch?v=QW85Y0Ug3KY .
Here's a couple tools that try to tackle this problem in different ways:
Yes, ksync and telepresence lets you develop on k8s cluster as if you were doing on the local system. Haven't looked at forge yet.
These tools are really useful when you're writing code dependent on other components or features on the cluster (like DNS). They save you a lot of port forward, environment variable hassles. Gives high velocity development flows, which were quite long build-push-deploy workflows earlier.
Would anyone know if there's audio/video of these lectures? I keep seeing amazing classes like this and wishing that everyone could enjoy them instead of just the local students.
The reason that cross-domain requests are disallowed has to do almost entirely with cookies. The concern is that since almost everyone uses cookies for identity, it is possible (without the cross-domain barrier) for a random web page to tell the browser to go fetch all their secret data and then return it to the malicious page.
This whole thing isn't an issue any longer if the server containing the secret data is expecting random people to access it and implements auth with something more than cookies. Take a look at Twitter and Facebook. They both allow cross-domain requests.
janky.post will only work if the server is expecting the request (it won't allow arbitrary requests to anything on the remote server) and then, it's up to the remote site's engineers to make these endpoints secure.
I've not done much profiling/performance (especially on older browsers) yet. My use case for the whole thing was to do a fire and forget POST to a separate domain.
Honestly, flash might be the best solution for something like you're talking about. I was just going for something with almost no dependencies that was stupidly simple.
I've done some interesting applications with Backbone.js over the last 2 months or so (for anyone that uses uTorrent, here's one: http://apps.bittorrent.com/ucast/ucast.btapp all in about 800 lines of code, just unzip the btapp file if you'd like to see the source). After trying other things like SproutCore, Cappuccino or Evently, I'll never go back.
I actually ended up being surprised by how backbone changed what I do with javascript. With backbone, you can create views that are really just widgets. For example, if you have a list item, you can create a view specific to that list item. Then, all the events and state for that list item are encapsulated right there. No need to store state in the DOM, you can just fetch it from the model when it happens. This then allows you to bubble events up through the parent views to change the entire page's state. Because of the separation, you really end up having little pieces of javascript that only know about themselves and the whole picture ends up being considerably less fragile and easier to debug.
I'm also a big CouchDB fan. Since backbone models are just documents, the integration with CouchDB is very minimal and you get instant serialization of user state (it really is that easy, to pimp one of my projects: https://github.com/pyronicide/backbone.couchdb.js). There are no server handlers you need to write (hell, don't forget you don't even need to run a web server, Couch'll do that for you!) and you end up with less complexity overall.
Right now, I'm just using qunit + sinon.js. I'm not super happy with it (I'd really like to get to the point where all my development is done via. writing unit tests), but so far it works. Honestly, one of the big advantages of backbone is that because of the structure it forces on your code, unit testing is easier.
Everything ends up being in a small testable chunk that you can stub out the interfaces for and test (see sinon.js, can't say enough good stuff about that). I've also got a small Backbone.sync implementation that just loads test fixtures and returns data from that, allowing me to have a db to test against that's fake and synchronous. With couchdb, all I have to do is take a DB dump of what I want to test, put it into a file in my test directory and I've got instant fixtures.
Any idea how easy or tough it is to integrate with JSTestDriver? I would like to use backbone for our projects but am finding it tough to implement TDD for Backbone controllers (for models its fine) because of the template. Through tests, I am not able to inject the DOM which is expected by the controller templates. I know this is off topic but if someone can help for the same, it will be great.
I'd suggest not actually using a bug tracking system. They tend to be separate from actual planning and the fact that they're separate means that planning is harder.
I can't recommend pivotal tracker enough. It's not a full featured bug/issue tracker like JIRA, but I think that's what I love about it (I also only really use it for projects with up to about 4/5 people on them). The interface is super easy to learn, but works very well for both bugs and features. You do have to prescribe to an agile style development cycle to get the most out of it, but alternatively, you could just leave everything in the icebox.
We use Pivotal Tracker at work and it's just awesome! I can't believe it's free, it's so good. At my last job we were using some enterprising scrum management software and it was slow, clunky, and expensive (unless you used the free version, which we didn't because heck, we've got an IT budget to spend and we need that burndown report!)
I've been using mixpanel's platform for a couple weeks now and have been super pleased with it overall. Being able to deliver stats to my end users has been a big success.
How are you planning on managing the publishing workflow for non-devs? Marketing and docs teams tend to struggle quite a bit with git specific flows.