Orkes is leading the next generations of platform that lets developers build highly resilient durable applications. We are also the creator and maintainers of Conductor open source orchestration engine.
We are looking for a software engineer, who is obsessed with helping customers be successful, is not afraid to dig into the code and is able to switch between languages like Java, Go, Typescript or Python (if not all, some) effortlessly.
Occasional travel required.
- Sr. Software Engineer - Customer engineering - 150k-175k + Equity
apply jobs at orkes io
We're looking for a Senior Java Engineer experienced with Java web app frameworks such as Spring Boot, and Postgres including data modeling and query optimization. You will be supporting the development of VECTR, a Purple Team analysis, reporting and attack automation platform. Our tech stack is: AWS, Docker, Java, Postgres, Vue.
Security Risk Advisors is a fast-growing cybersecurity consulting company. Our clients are concentrated in the Fortune 1000 and Global 1000. We have a fast-paced, agile, and fun culture that focuses exclusively on cutting edge cybersecurity engagements that solve the emerging needs of our clients. Our engineering team has a remote-first culture and supports product development and our consulting teams.
Interview process: (1) Recruiter, (2) tech screen with a manager, (3) experience discussion, (4) system design.
For more information and to apply: https://wrkbl.ink/2C7ZXeZ
Learn more about VECTR here: https://vectr.io/
Are you hiring folks who live in California? If so, you're missing the (required by law) salary range. (As well as other states who have similar laws.)
I find the Studio Display to be 2X what I'd be willing to pay for a monitor—for me the Thunderbolt Display was the best: reasonable price and great quality.
"JDK21 is a version, for which many vendors offer support."
tl;dr: the Java version is not what gets "long-term support", it's a specific runtime JDK released by some Java vendor, e.g., Oracle, Eclipse Adoptium, Azul, Microsoft, Amazon (Coretto), etc.
Right now, you have two main options:
Use a GET, and squeeze all the parameters you need in the URL or headers somewhere
Use a POST, and have the request considered as unsafe & uncacheable
Third option: you POST or PUT to a resource representing the search, then you’re free to redirect and subsequently GETs of this resource can be cached.Wanting a special method for search hurts the conceptual integrity of HTTP, where resource representation is the core idea to build on top, it isn’t supposed to be just a request/response protocol.
But that only means that specific instance of the search query is cacheable, not the search query itself, no? I presume the POST would create a new identifier for the resource, so that yes, that specific resource is cacheable. (Even if the server says "oh, I've just seen this POSTed query, let me return the same resource ID", another client will still have to POST to the server, a non-cacheable action.)
The idea of cacheable isn't just by the server, but by anything in between the client and the resource. By using QUERY, the query itself can be cached.
Deleted Comment
I remember submitting a stock charting application that Michael Risse and Nevet Basker used to love showing during the VB 1.0 launch demos (and road shows), because they could plot the chart of Microsoft (up and up) vs. IBM (not so up).
For me, VB 3.0 was peak Visual Basic, and I was on to doing Java stuff by the time VB 6.0 was released.
Fun times.