CLASSIC.COM | Software Engineer (Elixir) | Remote (Eastern Timezone) | Full Time | https://www.classic.com
We are building CLASSIC.COM a comprehensive platform for classic, collectible, and rare automobiles. As a leader in our vertical, our platform serves millions of users, and we are seeking two Software Engineers to help take our systems to the next level.
The Software Engineer (Elixir) will work in our Experience Team, which builds the complete experience for our customers. You'll use Phoenix + LiveView to build fast, modern, and efficient user experiences, and help continue to roll out Elixir to the rest of the organization. For more details or to apply, reach out to me at luke @ the company domain.
If you reach out from Hacker News, please mention that in the subject line or email body!
Both roles are full remote, we do have flexibility regarding country, however there may be some countries we're not equipped to hire in. Though these roles are full time, we're also available to do contract type roles if necessary. Not interested in any recruitment help.
We are building CLASSIC.COM a comprehensive platform for classic, collectible, and rare automobiles. As a leader in our vertical, our platform serves millions of users, and we are seeking two Software Engineers to help take our systems to the next level.
The Software Engineer (Python) will work in our Acquisition Team, which is responsible for connecting with 3rd party auction houses, dealers, and venues to bring their inventory into our system and performing additional enrichment to build our database of over a million classic cars. More details: https://www.classic.com/insights/now-hiring-software-enginee...
The Senior Software Engineer (Elixir) will work in our Experience Team, which builds the complete experience for our customers. You'll use Phoenix + LiveView to build fast, modern, and efficient user experiences, and help continue to roll out Elixir to the rest of the organization. More details: https://www.classic.com/insights/now-hiring-senior-software-...
If you reach out from Hacker News, please mention that in the subject line or email body!
Both roles are full remote, we do have flexibility regarding country, however there may be some countries we're not equipped to hire in. Though these roles are full time, we're also available to do contract type roles if necessary. Not interested in any recruitment help.
I'm not a customer, but having seen the workflows lawyers go through with documents this product would be extremely useful. I suspect your challenge will be that most laywers are likely risk averse, and would hesitate to put any important changes through something that is not well vetted. I wonder if there's a way to combat that by keeping your product compatible with their usual format, therefor making it a less risky product to try?
Timely posting! I've been inspired by some recent... large gaps in data at work (silent analytics processing failures) to build a service called QueryCanary. It's a surprisingly powerful but simple tool that lets you define scheduled SQL checks to run against your database, and then checks those results for anomalies, variances, and other issues.
Really hoping to get some early feedback on this tool, I've been using it for two production sites for about a week now and I've already discovered (at work) that we've had the 2nd largest user signup day, and that we deployed a change that inaccurately tracked a specific metric. Check it out at https://querycanary.com
I'm working on a workflow automation tool that lets devs write workflows in simple yaml files, and then deploy them to the cloud _or_ on premise. Each workflow is a set of actions and a trigger that can transform data, make api calls, run AI models, or really anything (via docker!). Each step relies on the output of the last step, and the workflow framework is engineering to be declarative, testable, and versioned. Similar to GitHub actions, but for *anything*. Think webhook to slack, email to support ticket, nightly aws backup & restore, mirror a file each night, etc.
I was able to do it pretty easily with a mobile app, should be just as easy on desktop. You could even register custom “pages” for various parts of the desktop app.
Really enjoy working with bits & bytes in Elixir. The syntax looks weird at first but pattern matching against an incoming message via individual bytes is very nice. I've found the gen_tcp / gen_udp stuff's documentation to be a little hard to grok as most of it only gives deep in the Erlang modules but once you "get it" you really get it. It plays very nicely with GenServer's too for super reliable, fault tolerant, tcp/udp acceptor clients. Thanks for the article, this will be a good resource for everyone to learn more about gen_tcp/udp directly!
Unsure why, but the arrow examples you have there show up as unicode code blocks for me in Firefox on a Mac. Probably one of the reasons not to use them like that!
We use it for our prod deploy pipeline to package the final image. Normal PRs are working because we cache the Ubuntu image, but prod deploys are fresh :(
Sooner or later, SSL expirations will come for you!
I've had really poor experiences so far from Elastic.co. Their core ElasticSearch offering seems to be on the backburner while they focus on "App Search" and other unrelated products like their APM offering. This leads to pretty sub-par knowledge and support for the ElasticSearch product. Even simple things like paginating results is an unknown, and you really have to pay deep into their ecosystem to get real implementation support.
Oddly enough too, due to the way their cloud hosting infrastructure works it seems they double dip into bandwidth pricing that should otherwise be free (eg AWS => AWS). It's also treated less as a "Software" as a service, and more a "platform" as a service, so you are left ultimately with the responsibility of managing, maintaining, and updating your Elastic cluster, without any ability to SSH into the servers its running on.
Then there's the unprofessionalism of laying off your account manager during a client call, or telling your client that you're sorry their ElasticSearch infrastructure is down, but they can't really help you unless you're on their "Sapphire Extreme Plan" [sic]...
Even if OpenSearch is just a cog in Amazon's offering, at least it's of a known quantity.
As a volunteer firefighter in Pennsylvania the halligan is generally the tool I reach for when doing interior operations. Besides the obvious uses of breaking a door in / breaking glass, it actually can be used for near anything. Searching for a victim, poking small holes in the wall to check for fire extension, using it as a ladder to get out of a tall window, etc. I haven't found much personal use in carrying an axe in, but a common set of tools is called "irons" which is your halligan and a flat head axe.
For forcible entry the halligan is _the_ tool to use, check out how quickly it can pop a lock when combined with a flat head axe and a k-tool: https://www.youtube.com/watch?v=LLCAcCuLKE4
Exterior is a completely different story, where the pike pole or pike pole + multitool really shines. You'll use it to check the roof for stability, poke holes to find extension, and after cutting a hole using it to open up the roof and poking your way through the drywall / insulation.
Looks like the website is actually a thin layer of JavaScript that converts the blog post from markdown, injects it as HTML, and then renders the comments below it. Without JS the site is just a hidden textarea.
MTUs are fun. We (live video streaming platform) were recently investigating issues with users having trouble watching our live video streams when using a VPN. Since we're using WebRTC on the viewer end we thought immediately it was just some WebRTC "protection" trying to not leak the users IP.
Eventually we figured out that Open Broadcaster Software has a compiled configuration of a max MTU of 1392 for the UDP packets we're sending. Generally this is fine because most routers have a default MTU of 1500, however when coupled with some of the VPN technologies, it ends up pushing the MTU over the limit and the video packets get dropped.
Overall MTUs seem to be slightly a not well understood thing, because answers on the internet wildly vary for appropriate ways of handling it. The consensus from some Google/WebRTC folks seems to be that 1200 is a safe and fast default.
> Anyway, 1200 bytes is 1280 bytes minus the RTP headers minus some bytes for RTP header extensions minus a few "let's play it safe" bytes. It'll usually work.