They've been the only game in town for a while, and their pricing reflects it. But this project is only for Python (for now?) so JFrog is not _immediately_ in danger.
I used GitHub for years in the tech industry, then went into the games industry and used BitBucket and hated it, thought it was such a downgrade. Now I'm back in the tech industry and using GitHub, and I miss BitBucket.
Starting to pretty much desire tools that can do nothing but are just fast at their core competency.
Looking at PRs in github and then when toggling to the "files" tab it chocking up or being like "I don't want to display this file because its more than 100 lines" is like wtf you're whole point is to show me modified files.
I wish the world worked this way, but I don't think it does, especially in tech. If you "do one thing well", the cloud hyperscalers will use their billions to copy whatever that is, and add your "one good thing" into their bundled subscriptions or cloud plans. At which point, any rational CTO will go "why should we pay for this, when we're already getting it via AWS/O365/whatever, and with better integration with our existing tooling to boot?"
I don't think "do one thing well" can succeed in this world, which is why Atlassian, Dropbox, etc. keep on launching things like office suites even though that makes no sense considering their core competencies. It's the only way not be streamrolled by FAANG.
I've seen it mentioned in the context of smaller countries competing with the big guys using industrial policy, and one example mentioned in that article (I don't have a link - it was long ago) they specifically mention Sweden and Volvo.
We use so many cloud services and SaaS products that it will be quite a shock how fast systems can be. You don't even need to use a local service, just hook up a minimal server somewhere that pulls from slow services here and there. Technically cloud, but not as shitty.
I think modern wait times are crushing for productivity, it is really demotivating and wears you down. Either just skip to another task and get overwhelmed by context switches or you wait and degenerate to a non-thinking troglodyte.
Github's problem is that it isn't a SPA. It is a massive Ruby on rails project that is all server-rendered. Everything you do needs to be synchronous and almost everything requires a reload.
A react or angular app with great restraint would be dramatically faster at all of this as viewing a file is just an API call - not a page reload. They are stuck with their hands tied as loading large data would cause the whole page load to be delayed - thus silly limits.
Many things should not be webapps... but an app on the web like this...probably should.
> Everything you do needs to be synchronous and almost everything requires a reload.
this is pretty incorrect, you may want to look into the concept of "partials" in SSR.
maybe you meant everything requires a roundtrip ? but SPA would not solve most of the roundtrips necessary in github given many interactions in the github app require authn/authz checks.
would you care getting into more details ?
Also, 'old' github was known to be very fast an reliable and was indeed a ruby on rails SSR app.
Since a few years ago github started to introduce react and more client side logic and it correlates with more issues and more slowness in the frontend. It only correlates, but still.
You can have parts of the web app rendered on the client, and still keep the rest of the app the same. Rewrite the diffs and previews, keep the rest as-is.
There is no excuse for possibly the most used feature of Github to suck so badly.
I've worked at two game companies and both used both of them. And I went to grad school for game design and used Perforce. So yeah I've ... had the experience.
I liked the UI of BitBucket more. Stuff I accessed frequently like commits and branches were tabs across the top, easy to reach from any page. Branch dropdown sort order was by most recently updated unlike GitHub where I have to search for it. Easy to diff files. This was like 4 or 5 years ago though, maybe it has gone through modernization/enshittification. GitHub feels a bit fragmented and it tries to be more performant by virtualizing some things but while BitBucket in some sense was more rudimentary and showed it all (bogging my machine down some), it allowed me to CTRL + F easily with more confidence whereas with virtualization I've had issues with it finding things and I couldn't 100% trust it.
Of course, but there are some oddities in tool use compared to other industries. At my job we use Perforce for version control for example, which I think is more common in the game industry than other solutions for whatever reason. Naturally everyone here hates it.
> Perforce for version control for example, which I think is more common in the game industry than other solutions for whatever reason.
The last game I worked on was like 80gb built. The perforce depot was many terabytes large, not something you want to have on every person's workstation. Games companies use Perforce for a very good reason.
But not everybody here has to try and manage many GB or even TB of assets in their VCS. I wager game company build/dev engineers know what they are doing in picking Perforce.
You're comparing politics regarding actual political events and private code being scraped without opt-in or permission being requested, what is going on here indeed man.
I always hear this but people use Siri all the time, and I think outside of talking to programmers, a lot of consumers probably consider that the level of AI they care about using. "is Siri really AI" seems like a real "is a hotdog a sandwich" question. Who cares? People eat hot dogs and talk to Siri.
It seems what Apple has less of is LLM products that cost enormous sums of money to make that people don't like using. Sure, they have a little of it, they fell flat on their faces with their news summaries thing last year and AppleVision was a nothingburger, but when it comes to "sinking huge amounts of money into deeply unpopular ventures", it seems to me that Apple's reluctance to deploy its largess here might be prudent. It seems like they're less exposed on the hype.
I do wish Siri was a little more intelligent to be honest.
I use Siri when I need a fast, distraction-free, action. Which makes it perfect when driving or performing other tasks where my hands a busy and/or I cannot put my attention on my phones LCD screen.
The way Apple paired with ChatGPT is awkward. You get prompted if you want to use Siri or ChatGPT. Which creates a distraction.
I'd love it if Siri was smart enough to differentiate between:
- an automation request. eg setting an alarm or ringing a contact. The kind of interaction what you wouldn't want to offload to a 3rd party but is the kind of interaction where you don't need vast datastores of training.
- and an open-ended question. eg What time are Oasis playing in London tonight? Who was the 23rd President of Germany? What are the rules of Dodgeball? these sort of things are less confidential and don't require handing control of your phone to a 3rd party.
And I'd love it if Siri automatically offloaded from their local AI to ChatGPT (or whatever) when the latter was identified. That should be opt in, but when opted in, it should be automatic. I shouldn't have to consent each time after I've opted in.
> The way Apple paired with ChatGPT is awkward. You get prompted if you want to use Siri or ChatGPT. Which creates a distraction.
My hunch tells me this is a temporary stopgap until Apple figures out their "private cloud compute" or whatever where they can run their own model, after that it'll be seamless. Try to do as much on device as possible, and if that fails/is not possible, offload to the model running on Apple's servers rather than a 3rd party service.
Maybe they're "behind" (although, this tech is still so early I don't think anyone is truly behind), but I appreciate their approach to try and do as much on device as possible. They are the only ones around that aren't just defaulting to "harvest as much data as possible and ship it to our servers."
I can be patient - Siri works fine for what I want it for anyway - it can set reminders, timers, alarms, dictate messages, and create notes. That's about all I use it for and would use it for. Anything else I'm not going to ask my phone, I'm going to take it out and head to Google.
> Anything else I'm not going to ask my phone, I'm going to take it out and head to Google.
But my while point was there’s a plethora of different reasons why “heading to Google” isn’t always practical. Like when you’re driving. When you’re cooking. Even when you’re just playing with the kids, a question gets asked, and you don’t want to spoil the momentum of the play by staining at an LCD screen for 2 minutes.
Siri really damn convenient for those occasions when you want an action performed but don’t want the distraction of performing that action.
In fact, I’d go further and say that’s the biggest selling point for current gen consumer AI.
> Maybe they're "behind" (although, this tech is still so early I don't think anyone is truly behind)
The tech is still early but Siri are most definitely behind.
It’s not even remotely close to the capabilities of even open source models, let alone the commercial ones.
And the fact that they had to bolt on ChatGPT in such an ad hoc way speaks volumes about how Apple realise themselves just how far behind Siri has gotten.
I think you’re right that it’s not their long term plan. But that doesn’t change that it presently feels like a very ugly kludge.
I'm not sure if you're in a country that has already received some upgrade, but over here in Europe Siri is seen as a funny tamagochi that sometimes misunderstands and thinks its needed and is then quickly told to shut up.
I think the last time I talked to anyone about siri we were wondering why it was still so bad, now that we have LLMs.
I've never seen people in europe regularly using siri except to bash how bad it is. I would be really interested taking a look at the secret usage stats of siri in europe compared to other regions.
There was a time when I hated livecoding interviews, but anyone who has ever participated in an interview process that lacks a livecoding interview and wound up hiring someone that literally could not code knows that a bad hire is incredibly painful and expensive. For most employers, missing out on a good candidate is a less expensive mistake than hire a bad candidate.
The post describes what candidates can do, but there's a lot of responsibility on the end of the interviewer. Most of the responsibility, if not all of the responsibility here, is on the interviewer. If you're seeing 75% of your candidate bomb your livecoding interview, your process is very, very broken.
- Never spring a livecoding question on someone as a surprise. Candidates should know well in advance which portion of an interview has a livecoding question in it.
- Interviewers are responsible for helping the candidate feel comfortable. I always chat a bit with candidates, explain the schedule of the timeslot up front, read through the problem with them, answer any questions about the problem they have to make sure they understand what is being asked, etc.
- Always give more than enough time. A question that you expect to take 10-15 minutes to solve requires an hour long interview slot. For candidates that finish very early, have a bonus question lined up in advance, or use the time to talk and answer candidate questions. E.g., for a 10-15 minute problem, you could do a 5 minutes intro, 40-45 or minutes coding, and a 10-15 minute outro for candidate questions.
- Don't make the problem too small. If it's too small, you're quizzing them on knowing a single thing and not gathering any signal on whether or not they can break a problem down. One medium problem that breaks down into two smaller subproblems is better than two small problems that have nothing to do with one another.
- I tell candidates they can pick what language they want and I also tell them what languages I know.
- Frame it more as a pair programming exercise. If the candidate wants to do something that requires a lot of typing, I'll pitch in. If they make a typo in a variable name, an indentation error in python, or drop a parenthesis, I just tell them. It's not a typing test.
- I tell people they can look stuff up. I even tell people they can ask me. If someone asks me a question about the Python or Go standard library I just answer it. It's not a test of your memory of the layout of the Python standard library. If you vaguely know "the standard library has this thing that I need" and can name it, I'll just tell you where it is.
- I tell people they can run the code as many times as they want; if they want to run their code a bunch of times and solve it in an iterative fashion that's totally normal. Without this instruction, sometimes candidates think they are expected to get it right on the first run, or in as few runs as possible. We're not golfing here.
etc. Things like that. Sometimes people tell me what they're going to do and ask me if it will work and I'll say "ah I think that's giving too much away", so there are limits. Obviously don't solve the problem for people, but making sure the candidate is comfortable is something the interviewer must actively engage in and manage, and when candidates are getting stressed out, it is the interviewer's job to do their best to help lower the stress level of the situation. And yes, sometimes you'll still get people who bomb, but if you're seeing that happen 75% of the time, that's likely signaling that your process is not working.
I don't really think that's accurate. In my last interview cycle, I aced the livecoding portion at each interview and didn't practice any leetcode problems at all. In my normal workflow I write utility scripts in Python using only the standard library pretty regularly. If you know how to write complete, small programs using only the standard library of some language, you'll do fine on livecoding interviews. A lot of people struggle to do this because they only know how to work inside of a framework.
Maybe they didn't give you the same sets of problems most companies use.
Last time I went through any of these one of the problems was implementing a priority queue, for which I would have to write a min-heap on the spot. There's no chance I'd be able to do it on 45 minutes with an interviewer breathing down my neck.
In other situations I had easier ones. I don't remember the problems especifically but I recall one I googled after the interview and the answer was using two-pointers fast/slow to iterate through a list. I spent maybe 20 minutes tryng a couple different approaches and that one never occurred to me. Last time I had to use a two-pointer solution for a problem was at uni, which I left 15 years ago.
But then again they could still force you to use another language (as I had to during my interviews) and even though strict syntax isn’t required it still throws the candidate off.
That sounds terrible for all parties. You have to conduct the entire interview experience twice, the candidate has to conduct their job search twice, they may have declined another offer to accept yours, they may have had to relocate to accept your offer, if you're in the US they may have gone off health insurance and their new health insurance didn't start yet, etc.
I think this narrative gets recycled because it's the shallow depth of reasoning afforded by thinking about technology only by thinking about the instruments of that technology and one's own personal experience with them, which is the perspective that is prioritized on HN.
jfrog artifactory suddenly very scared for its safety