Location: SF til ~Xmas, then TBD
Remote: Yes (fully or hybrid)
Willing to relocate: Yes, especially out of USA
Technologies: Kubernetes + DevOps-y etc. [Enthusiasticly:] Rust, Elixir, shell(s), HTML/CSS/etc; [Less enthusiastically:] Go, TypeScript/JS, Ruby, C, …; [Begrudgingly:] Python, Java
Résumé/CV: https://drive.google.com/file/d/1Q5Pf8aRO6WDlAQ_3oveBs0O2M7Ki25El/view
Email: donald.b.guy@gmail.com
Hi. I’m an MIT-educated software generalist leaning DevOps/infra, w/ about 10 years in software industry… up til early 2021. Then I had a nice, long, self-financed (via previous startup RSU-sell-off) sabbatical, but now need rather urgently to return to working for a living.
[Unfortunately for this time and place,] I am pretty unenthusiastic about both AI/ML and “AI”, but I am interested in dev tools, IoT stuff, hardware-software systems broadly, education, green energy, A/V production & distro, new-wave social/indieweb, civic tech, … and probably amenable to a lot more missions I haven’t especially considered.
I'm comfortable jumping up and down levels of abstraction and I like making things work together well. I'll call myself "full-stack" but in truth I tend to be most interested in all "edges" (HCI, API, hw/sw).
I have never been very good at job-acquisition (and it's only gotten worse), but I am pretty sure I could add a lot of value a lot of places if given the chance.
Yo I love phabricator; it's one of my favorite pieces of software, but three things:
1. The title's seeming attribution to Wikimedia as opposed to Facebook (or even Phacility) is like, whatever the opposite of dog whistling is
2. If you want to host your own things, great; do that. Phab is great, gitlab is also pretty neat. If you want someone to manage this stuff for you, Phacility is out there grindin' but they also have like O(10) employees, so don't expect miracles
3. The point of GitHub was always about "social coding"; the concerns about overcentralization aren't unfounded but it's also not like that wasn't straight up the value proposition in th the first place!
If everyone moves off to their own walled gardens, something of value will be lost. So like, again: love phab (it/arc's my favorite code review workflow, I think the conventions it adds on commit messages are really valuable (and btw trace right back to Facebook eng culture), the pretty tight integration of tools is nice, I enjoy its sense of humor), but I think calling it meaningfully a true GitHub alternative, with any consideration of FOSS, is inaccurate
Disclosure: I left a startup using phab (at my urging) and GitHub at the end of March and now work at Microsoft (where my team has some code on VSTS and some on GitHub). I first encountered Phab as an intern at FB in 2011, when epreistly had just left
It has @mentions, notifications, and the ability to have some Google-Docs style inline comment threads, so depending on the use case I'm not sure you'd totally miss it
Otherwise perhaps phacility-hosted (so cloud) Phabricator, wherein it is mostly (a less unified UI) project management system but has the realtime chat component available in https://www.phacility.com/phabricator/conpherence/
You could alternatively OAuth sign up for the chat.zulip.org server used for project development and see the feature in action there (https://zulip.readthedocs.io/en/latest/contributing/chat-zul... ) so long as you kept testing traffic to the `#test here` stream :-)
We used to do that, but it turns out that having the Internet visit your chat community without any briefing isn't the best plan. Linking to the ReadTheDocs page has helped a lot in making sure people joining the community have some sense as to what to expect (e.g. that it's at times running a super beta version of Zulip, or that people are doing actual work, that we have a code of conduct, and you should send your test messages to #test here).
Very differently. Slack does threading on the basis of replies to a message and hides/collapses those under a thread, showing them only to people who expand and notifying only those who are already involved in the thread (by replying to it or being OP)
Zulip's threading is based, more like email, on a Subject which all messages (can) have. Though Zulip subjects are more likely to be one or two words.
In this way threading is tacked on to Slack whereas it is as at the heart of Zulip
Threading in email works via message-ids and references to preceding messages, nothing to do with subjects. That is, except as a workaround for garbage email clients and services too incompetent to use email correctly.
I mean, depends on your MUA in practice. I think by standard for server side threading— https://tools.ietf.org/html/rfc5256 — "base subject" is definitely a valid consideration. I only skimmed though. :-) feel free to extract a spec, I'm curious (but not enough to read 19 pages right now)
ORDEREDSUBJECT
The ORDEREDSUBJECT threading algorithm is also referred to as
"poor man's threading". The searched messages are sorted by
In other words: as a workaround for garbage email clients and services too incompetent to use email correctly.
Yes, the REFERENCES algorithm also uses the base subject--but never to override message-id based threading, only for merging together threads that couldn't be joined using message-ids ... or in other words: as a workaround for garbage email clients and services too incompetent to use email correctly.
Well, and for merging together chunks of a thread where you have major gaps in your mailbox, so that reference headers don't overlap enough to make the connection, but the point remains that it's not really a threading mechanism, just a last-ditch attempt to recover a thread where proper threading information is missing, which is fine for corner cases like large gaps in which messages you have in your mailbox, and doesn't change that a sender that doesn't supply reference headers in the first place is incompetent.
I feel like a little background would help this thread. I vaguely know/knew some of the founders, but am not really in touch anymore
Zulip was started as, and basically still was last I used it, a modernization/web-ification of the BarnOwl[1] curses/terminal client for, mostly, MIT's (and CMU's, inter alia [2]) legacy Zephyr[3] IM protocol. (though BarnOwl also has support for XMPP, IRC, AIM, and Twitter). MIT students who were into the zephyr community also tended to like the interleaved-thread with option to narrow to specific filters view. The Subject part of threading comes as largely an accident of Zephyr's implementation[4]
and subsequently open sourced in 2015. Zulipchat.com is a second company formed around Zulip by (OP) one of the original founding members of the pre-acquisition company to (I'm speculating) keep the project healthy and active and give people a hosted option. It is not primarily aggressively pursuing market share, capitalization, etc. That is why it doesn't like price aggressively to compete with Slack, etc. as someone EIT was confused about
I took the time to spin this out from memory, etc. but then I found it was mostly covered (or if you prefer corroborated) here: https://zulipchat.com/history/
Anyway its a good model for organized communications once you get used to it and I'd recommend it if you are in a small enough company/team with enough latitude to experiment with such. It would also be cool to see a decent large public instance as an alternative to ~Mastadon
helm recently(ish) added a helm template command to do client side rendering of a chart
So if you wanted to just create a folder with a Chart.yaml, and a templates/file.yml.tpl with some `{{.Values.foo}}` template strings
It is sufficient to just run `helm template --set foo=bar | kubectl apply -f -` at that point.
Idk if that is little enough complexity for you. Similarly I use https://github.com/gliderlabs/sigil a few places where I want to include specific fields from external json files
Mostly the answer is "if you want to do it all yourself, go for it";
Things like this, and especially Kubernetes, are about creating a common and agreed upon language for infrastructure - both patterns and specific "off the shelf" applications
And likewise the common language/interface creates opportunities for wider coverage and easier adoption in tooling for monitoring, autoscaling, smart routing (see "service mesh"es), etc.
You may not need all of k8s functionality immediately but it's the agreed upon common core for modern distributed systems functionality
And to everyone's credit it's also being done pretty much as modularly and extensiblely as we could hope for
Do you want to help build the factory of the future and realize the next industrial revolution?
Tulip is transforming manufacturing processes by bringing the latest technological advances from the lab to the back office to the shop floor. Whereas most factories are still using state of the art technology from the mid 19th century, we come from the future to bring them a rich, realtime web app, modern tablets, IoT systems, in-depth analytics, and more.
We're a small team, but we have multiple Fortune 500 customers and are enabling production lines building things you interact with everyday. We're in a strong growth mode! We closed a $13M Series A last month (http://tcrn.ch/2qYvsoN), we are bringing on new customers, scaling up our existing customers' deployments, and, most relevantly, hiring across the team!
We'd love to talk to anyone interested, but in particular we are looking to bring folks on in:
- Web Development: Meteor+React+Redux, delivering useful, real-time experiences in the browser and on Electron
- IoT/Embedded Software: delivering a reliable, extensible HW platform across arm and x86, all manner of bus/IO tech
- SRE/DevOps: Kubernetes-admin, scalable monitoring across the firewall, hybrid cloud/on-prem deployment
- Data & Pipeline Engineering: planning, implementing, and finding insights with our next generation of process & sensor analytics
- Design & Product: Usable, beautiful UX that makes the above worth doing
[Unfortunately for this time and place,] I am pretty unenthusiastic about both AI/ML and “AI”, but I am interested in dev tools, IoT stuff, hardware-software systems broadly, education, green energy, A/V production & distro, new-wave social/indieweb, civic tech, … and probably amenable to a lot more missions I haven’t especially considered.
I'm comfortable jumping up and down levels of abstraction and I like making things work together well. I'll call myself "full-stack" but in truth I tend to be most interested in all "edges" (HCI, API, hw/sw).
I have never been very good at job-acquisition (and it's only gotten worse), but I am pretty sure I could add a lot of value a lot of places if given the chance.