Harvard Library Innovation Lab | Senior Software Engineer - Full Stack | Remote (some US states) or hybrid | Full-Time | https://lil.law.harvard.edu/
The Harvard Library Innovation Lab is a software product studio and research lab embedded in the Harvard Law School Library, with a mission of bringing library principles to tech. We are currently working on projects including web archiving, remixable education resources, and AI as a new way of accessing knowledge. As a member of our engineering team, the Senior Software Engineer will work across our various tools, applications, and experiments. The ideal candidate will have experience building performant, testable, maintainable, and fault-tolerant products and tools at scale, for audiences both technical and non-technical.
You can apply here: https://lil.law.harvard.edu/jobs/#sse-fs. Please include a short cover letter explaining how your career trajectory and interests align with our work and mission.
Harvard eligibility is weird: we can hire hybrid near Cambridge, MA, or remote only if you live in the states of CA, CT, GA, IL, MA, MD, ME, NH, NJ, NY, RI, VA, VT and WA.
Harvard Library Innovation Lab | Senior Software Engineer - Full Stack | Remote (some US states) or hybrid | Full-Time | https://lil.law.harvard.edu/
The Harvard Library Innovation Lab is a software product studio and research lab embedded in the Harvard Law School Library, with a mission of bringing library principles to tech. We are currently working on projects including web archiving, remixable education resources, and AI as a new way of accessing knowledge. As a member of our engineering team, the Senior Software Engineer will work across our various tools, applications, and experiments. The ideal candidate will have experience building performant, testable, maintainable, and fault-tolerant products and tools at scale, for audiences both technical and non-technical.
You can apply here: https://lil.law.harvard.edu/jobs/#sse-fs. Please include a short cover letter explaining how your career trajectory and interests align with our work and mission.
Harvard eligibility is weird: we can hire hybrid near Cambridge, MA, or remote only if you live in the states of CA, CT, GA, IL, MA, MD, ME, NH, NJ, NY, RI, VA, VT and WA.
Lack of physical escape key with vi is not a problem for me. An old trick is to remap caps lock (never used) to Ctrl (constantly used), which is easier to reach from "asdfhjkl" hand positioning. Then Ctrl-C is mapped to escape, and I never have to reach up to the fn row from the home row. Makes working with vi a bit more seamless and this lack of fn row is a moot point. So maybe we have to change few key bindings for ancient but still useful software. Really not a deal killer.
We've been working on identity and access management infrastructure software for a few years now. We're committed to keeping our projects free and open source (MIT), and we've been fortunate to sustain the effort by working for users that need specific features implemented or help with integration. Our primary project is an authorization server called Anvil Connect:
There's an explosion of change happening in this field right now, both from within and from new frontiers like IoT and blockchain. We have plans for things we'd like to build, and we're looking for forward thinking users that need them built.
Little late to the party but have you considered using something like an authorization server?
We created Anvil Connect (based on OAuth 2.0 and OpenID Connect) to solve a bundle of auth-related problems all at once. It's a separate server instead of a library, because once you need to share user accounts between several apps (think different platforms) the complexity increases dramatically. There are (third party) client libraries available for a number of languages.
We might be a good fit. At Anvil Research we need help with documentation, blog posts, tutorials, and user guides for Anvil Connect. It's an open source identity hub built with Node:
In fact, unlike previous OpenID protocols, OpenID Connect is a profile of OAuth 2.0.
The conflation of authorization with authentication is an accident and a mistake. They are still quite separate concepts. Authentication is about verifying identity. Authorization is about privileges afforded a given identity. Access control models usually depend on some form of upstream authentication.
The third-party authorization flows provided by OAuth are not intended to establish or verify a user's identity. Their purpose is to extend a user's access to a third-party in a limited way without sharing passwords.
Social Sign-in is an accident of 3-Legged OAuth and its use for this purpose is considered a very weak form of authentication.
OpenID Connect takes the best ideas from preceding identity protocols and incorporates them into OAuth flows, giving the best of both worlds.
Understood, and I'm glad to live and let live in general, but this one is too close in subject matter to my own work and may eventually lead to confusion about who's doing what. That seems like a reasonable cause for concern.
This is an interesting looking project, but I have to say I'm not crazy about the author's use of the name Anvil. I've owned the domain anvil.io going back several years, I've been actively using variations on the name Anvil for security related software that's in production for a period of time as well. If the authors of the project read this, please consider renaming it.
In the city, I couldn't possibly agree with this more. When I lived in Boston I sold my car after the first two years because it was a ridiculous expense and hassle for the utility. Taking a cab a few times a week turned out to be cheaper than parking tickets alone.
Given a choice though, I much prefer to live in less densely populated areas (e.g., northwest Montana), and owning a vehicle is really unavoidable. In these places that also means a 4x4 SUV or truck, not a Prius, or else you'd be calling a tow truck every 5 minutes in the winter.
"ICE Code Editor is the JavaScript 3D visualization programming environment used throughout the book 3D Game Programming for Kids. It's written with Dart, the language for scalable web app engineering from Google. In this hangout, prolific blogger, author, and coder Chris Strom takes us on a deep dive into the ICE source code."
Watch it live, join the hangout, or check it out later on Youtube.
This may not be any indication. A Firebase competitor named GoInstant was bought by Salesforce, used to build a few things internally at that company, and very recently shut down and the team integrated into the parent company. Any outsiders that built anything with GoInstant were basically out of luck. I have no idea how many users they had, and Firebase has greater visible traction, so that may factor in as well.
I didn't take it personally at all and if you have the time and inclination I'd love to hear more about your experiences. Please feel free to email me. smith at anvil dot io.
> Before making suggestions like this and getting the HN bandwagon to support this POV, perhaps we should put ourselves in the startup's shoes?
As a founder, I am in a startup's shoes, and my intention was not to provoke an angry mob, but merely to state my own opinion. I don't want to use Firebase for anything my own revenue will depend on, and that's a shame, because they have made an awesome product.
> Forcing an open source on acquisition severely limits your exit options and lowers your acquisition value.
These acquisitions of 3 year old companies are always sort of disappointing to me. On the one hand, I'm truly inspired and encouraged see their measure of success. On the other hand, I'd really like to see more startups committed to building lasting companies that strive for win-win outcomes that include users, employees, investors and founders. This isn't supposed to be a zero sum game.
> As much as the users feel like startup founders owe them something, startup founders are human like everyone else. They don't exist to be our slaves.
With a company like Firebase, there's a chain of trust that's really important. They are not responsible for just their own individual users. They are responsible for other companies' users. The effects of everything they do are multiplied accordingly.
Part of offering a platform is the guarantee that "this thing you depend on to serve your users will not go away unexpectedly without leaving a viable alternative." That's not an unreasonable thing for someone to demand when they're building their house on your foundation. Their use of your service also represents an investment of their own developer time. You go away, they lose that investment. If you as the operator of a platform don't want to take on that level of responsibility, don't go into that business.
> Imposing rules like this on companies would result in fewer tools and companies overall as the companies themselves would no longer make economic sense.
Who said anything about imposing rules? You're putting words in my mouth.
This isn't perfect and it contradicts my point about wanting to see sustainable companies, but I find it encouraging nonetheless. I think Firebase could have easily fallen into this category.
Don't forget about persistence. Creating a horizontally scalable database isn't likely to be a trivial matter. Somehow I don't think Twitter Bootstrap is going to be much help there.
Firebase has solved many harder problems than you and I are ever likely to have to deal with and they deserve full credit for that.
I'd like to take that devil by the horns and strongly suggest that companies like Firebase, who clearly deliver a critical infrastructure dependency for anyone using their service, should open source their platform as an act of good faith toward their customers.
No one wants to run yet another cluster, but anyone with an eye to business continuity ought to want the assurance that they can migrate to and from their own servers if that need should arise.
That might not be in the short term interests of Firebase, but it's definitely in the long term interests of their customers. Why would anyone ever base the future of their own business on the exit needs of another company's investors? It is a ridiculous risk. As much as I love what Firebase has built, I'd never use it for anything more than a toy project for that exact reason.
Basho, ElasticSearch and Docker(?) seem to be on a good path with commercial open source models. Is there any reason that a startup like Firebase couldn't do both? Offer their open source product as a service with non-critical value adds? GitHub is another example that comes to mind. If they were to get bought and shut down, it would be a pain in the ass to set up new remotes, but no one would have to stop using git.
The Harvard Library Innovation Lab is a software product studio and research lab embedded in the Harvard Law School Library, with a mission of bringing library principles to tech. We are currently working on projects including web archiving, remixable education resources, and AI as a new way of accessing knowledge. As a member of our engineering team, the Senior Software Engineer will work across our various tools, applications, and experiments. The ideal candidate will have experience building performant, testable, maintainable, and fault-tolerant products and tools at scale, for audiences both technical and non-technical.
You can apply here: https://lil.law.harvard.edu/jobs/#sse-fs. Please include a short cover letter explaining how your career trajectory and interests align with our work and mission.
Harvard eligibility is weird: we can hire hybrid near Cambridge, MA, or remote only if you live in the states of CA, CT, GA, IL, MA, MD, ME, NH, NJ, NY, RI, VA, VT and WA.