Meltano | All positions are full time and remote | https://meltano.com (follow the code blocks on our website for a demo!)
We're a seed stage startup that recently spun out of GitLab. A bit about us:
Meltano is an open source DataOps platform that brings together best-in-class open source tools and technologies for the data lifecycle, including the Singer standard for data integration, dbt for transformation, Airflow for orchestration, and soon Superset for visualization. It simplifies configuration, deployment, and monitoring, and lets data teams benefit from DevOps best practices such as version control, code review, and CI/CD.
Stack: Meltano and the Meltano SDK are written in Python. Vue.js (as part of VuePress) and Bulma CSS are used on the front end.
Thanks! This is really useful feedback. To date, Meltano has been geared towards data folks who are likely to understand these concepts and acronyms, but there's definitely a need to explain it for folks who aren't as familiar. We're going to be working on the website copy in the coming weeks to make it easier to understand with as little digging as possible. If you think of anything else please feel free to reach out to us.
This so much. It works really for your house too. I find that decluttering my physical and digital workspace at the end of the day means I'm not stressed about mess in the morning.
I'm really sorry to hear about the crappy experience you've had with GitLab. If you'd like to detail some more complaints, I'd love to hear them and open some issues about these things. Feel free to shoot me an email (located in my profile) or reply here. Either way, thanks for the feedback you've provided here.
As far as the frequent upgrades go, we've been using .com as a way of dogfooding GitLab at scale. Sometimes this goes well and other times it doesn't. We're actively working to improve this process so that downtime and breaking changes are less frequent. The end goal is to eradicate both issues so that upgrades are seamless.
Thanks so much for your kind words! We're always trying to improve, so even though some of the comments are negative, it's still good to hear about pain points so we can fix them.
One issue I encounter often-ish is that when I'm on a gitlab page then hit the back button in the browser - I get a bunch of JSON spit onto the page instead of an actual HTML document.
Most likely needs a Vary header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Va...) set to "X-Requested-With"; otherwise the browser will use whatever it has cached for the last request when you hit the back button (and if it was an Ajax request, that's probably going to mean a bunch of JSON).
Huh? Do XHR requests go on the navigation history stack? WTF? Why? And why would any site use the same URIs for API endpoints and frontend/view navigation places? And in that case should the Content-Type (or Accepts) be the main factor?
> Why would any site use the same URIs for API endpoints and frontend/view navigation places?
Simplicity. Ruby on Rails facilitates that approach, for example.
> And in that case should the Content-Type (or Accepts) be the main factor?
Content-Type, yup! Unfortunately Chrome and IE 10 (not sure about Edge) disagree on that.
Without the Vary header, the back button leads to rendering what the server last returned, without taking the Content-Type into account - which is completely nonsensical in my opinion.
Ironically, the section of the HTTP spec they initially referenced in that Chrome bug as justification for closing it as WontFix is precisely the part which explains why Chrome's current behavior is incorrect. Specifically:
> History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.
Doesn't matter whether a Vary header is sent or not; when a user clicks the back button they should see exactly what they saw when they previously viewed that page; regardless of whether that content is cached or not.
No, I think the OP is suggesting that the same URL will have been requested in both JSON and HTML formats, and the browser cache is not differentiating between them.
Yes, I understand that, but that seems crazy on multiple levels.
Why the X-Requested-With should be in Vary when the same client did the request? (Yes, I see, Ajax libs populate this field, whereas usual browser navigation doesn't. Makes no sense.)
Why is that resource in cache anyhow, when it should be Cache-Control: no-cache (or at least must-revalidate, but it probably is, but of course that again means that the cache returns the JSON after getting the 304 from the backend, because it doesn't differentiate between responses with different Content-Type)?
It seems to me that the X-Requested-With is again a hack on top of "representational state transfer", because it was easier than trying to use Content-Type.
I mean, I know RoR likes magic very much, but it's not totally surprising to separate the backend from the frontend.
And then use a SPA framework and use Ajax to communicate with the backend via a "REST API", because that simplifies the backend. A lot. You don't have to have views, templates, and so on implemented.
So either the REST API is not a REST API, but a lot of interesting endpoints for the frontend dynamic JS magic, or the frontend is not a frontend, just a lot of glitter thrown up on a REST API.
(I quickly tried to get something in JSON from a GitLab URL, but I just get a HTTP 406. :( )
I've actually experienced this exact thing. Usually a refresh fixes it for me so I never gave it too much thought. I'm not sure what causes it exactly but I'll follow up with the team about it. It usually happens to me on merge requests -- do you notice it on specific pages at all?
> Usually a refresh fixes it for me so I never gave it too much thought.
As someone who hacks on a SaaS with a sprawling feature set which ships often, I understand where you're coming from. But I would recommend giving things like that some thought.
I'm still not really sure, when I press the back button in Android, whether I'm going to stay in the same app, go to a different app, or close the app; all three behaviours are common.
Since the first part of your comment is addressed to Sasha I'll let her reply to it, but to address the second part:
There are multiple people involved in the hiring process here at GitLab, specifically several people who handle phone screens and resumes. The responsibility of vetting doesn't rest solely on one person and is actually a pretty collaborative process in my experience. As an example, I was able to vet every single candidate's resume myself for roles I was involved in hiring for.
With all due respect, the parent to my comment - an apparent employee at GitLab - said "I am the recruiter at GL". "The recruiter", not "a recruiter" How else is that to be interpreted? With whom does the candidate discuss compensation? This one single recruiter, or the manager of the team with whom the employee would be placed? Why does GitLab have a "recruiter", rather than an "HR employee" or "hiring manager"? The term "recruiter" generally means an external non-employee who is financially compensated for each new hire brought on board. "HR" or "hiring managers" are company employees, given a flat salary irrespective of the number or quality of hires. Which do you have?
Either way, the parent comment is full of language that raises red flags to competent developers. Personally, my first thought is "oh hell no!". It's possible that their comment is not representative of the company's effective policies, but when one perceives this kind of reply as an official stance of the company's standpoint, it is difficult to retract.
> With all due respect, the parent to my comment - an apparent employee at GitLab - said "I am the recruiter at GL". "The recruiter", not "a recruiter" How else is that to be interpreted?
The way I understood it, at least, was 'the recruiter who handled the interview with "matthewvincent"'. Doesn't imply that there are, or are not, other recruiters at gitlab.
And if so, at least to me it seems honest for said recruiter to come forwards personally, instead of some feel-good mumbo-jumbo from the PR department.
I'd LOVE to hear what red flags are in the comment from the recruiter or the other person - whom I guess is a manager. I've re-read it a few times but I see nothing but reasonableness. Then again, I'm neither a developer myself (does that make a difference) nor a recruiter...
Totally agree with this. Having to join 10+ Slack-like groups to collaborate on open source projects is unrealistic for me. As a result, I don't frequent some projects' chats and stick to bug trackers/mailing lists -- as a result of that I miss out on a lot of the camaraderie that comes with contributing to open source. I've missed out on a few conversations where decisions were made too. Being in multiple groups on these services is a huge pain point for me, whereas being on multiple IRC servers in multiple channels is far less invasive to my time and computer resources ;D. I'm not necessarily advocating that everyone use IRC for everything, but it seems like a lot of us had standardized on IRC for OSS before most of these services came along.
Also I'm salty that most of these Slack-like services have no ignore feature/minimal moderation tools which are both things I've leaned on heavily when working with communities. That's probably a rant for another day, but it's related to why I really dislike using some of these things.
This might just be my perception, but it seems like most people I come across in this field were on IRC at some point.
>most of these Slack-like services have no ignore feature/minimal moderation tools
This is what pushed me away from using Slack with a group of gamers I admin for. I can understand Slack's desire to stick to the workplace and how that leads to "if you need to /ignore a co-worker your company has problems implementing /ignore in Slack can't fix." And I can understand Mattermost wanting to become the opensource/on-prem analog of that. But it really falls apart when you try to use that kind of system with users that don't know you, aren't on your payroll or have issues with rules - like open source developers, or gamers.
My group eventually switched to Discord for, among other things, its amazing ACL-style permissions system, frictionless inviting and unlimited history (iirc, getting history with the first tier of paid Slack would have cost us ~11k USD/year?). It's not perfect - I really hope their bot API gets some love, and of course the ability to host your own server would be nice (though I understand some of the catch-22's there) - but I like it a LOT and I keep encountering new groups of people with Discord servers where I can just idle using one client. This is MUCH more IRC-like experience than I ever got with Slack (for instance, switching between or getting/setting notification alert levels on several different servers is much more ergonomic on Discord than on Slack).
I've not used Gitter a whole lot - just a couple of times when I had a question for some project that had one - but my impression is that it leans more towards "chat with strangers about $topic" (like Discord) and less towards "chat with colleagues about work" (like Slack). In that respect, I'd lay a small amount of money that Gitter does have an /ignore command, among other tools that you miss from IRC.
Valid point, but there are other things to consider. The reason I buy Windex is because it saves me time. Instead of buying vinegar, lemons, and rubbing alcohol and mixing them together with water every time I want to clean a something, I just grab the Windex/Lysol/etc. Likewise, I can spend time messing around with getting configs for various things in order, or I can one click deploy something to Heroku/AWS/DO/etc and not have to worry about it too much. It all depends on what's valuable to you.
I'd say that you can use the washing up liquid 'Fairy' (Dawn?) for almost all cleaning related tasks.
An exception is getting rid of limescale, where you need an acid. Citric acid works fine and does not smell.
If you have a wooden floor, a specially made detergent with a wax component is probably also a good idea.
I also have a machine with a private git repo that I keep some shit in - mostly half made things like an dead ant stack simulator, a non-working robot simulator controlled by a un-evolved neural network, a few heuristic Sudoku solvers, a really advanced configuration-management tool that might have worked at one point, and 20 years of random junk like that.
It actually also contains a GPU based Smith-Waterman algorithm using Aparapi that I think actually works and could possibly be moved to github without too much embarrassment. Maybe I should do that...
We're a seed stage startup that recently spun out of GitLab. A bit about us:
Meltano is an open source DataOps platform that brings together best-in-class open source tools and technologies for the data lifecycle, including the Singer standard for data integration, dbt for transformation, Airflow for orchestration, and soon Superset for visualization. It simplifies configuration, deployment, and monitoring, and lets data teams benefit from DevOps best practices such as version control, code review, and CI/CD.
Stack: Meltano and the Meltano SDK are written in Python. Vue.js (as part of VuePress) and Bulma CSS are used on the front end.
Open Roles:
- Backend Engineer - Senior Backend Engineer - Senior Frontend Engineer - Head of Partnerships - Content Marketing Manager - DataOps Evangelist - Senior Support Engineer - Technical Marketing Manager - Senior UI/UX Designer
Apply online at https://meltano.com/jobs. If you have questions please reach out to us on Slack: https://meltano.com/slack