Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Return of Fancy Tools

macwright.com

Post reply on HN
Print view View original

131–140 of 224 posts

Re: The Return of Fancy Tools

#131

Post by zozbot234 »

solraph wrote: post #79
jruthers wrote: post #72

Earlier quoted context omitted.

Right. The idea that Jira has been replaced made me laugh. There's probably a crowd of people that want to move on to the next issue tracker flavour and that's fine but I've got work to do that isn't tool shuffling. I'll use the one that integrates with so many of our systems and, though flawed, does a great job.

That integration piece is key. The people who want to replace Atlassian tools usually focus one part of the suite (usually Jira or Confluence), but to replace them you all you need a set of tools that work together. It's not just issue tracking, but alerting, issue management ITSM tools, source control, CI/CD, release management, documentation and I don't know what else that all need talk to each other and provide tr…

> It's not just issue tracking, but alerting, issue management ITSM tools, source control, CI/CD, release management, documentation and I don't know what else that all need talk to each other and provide traceability from any point to another.

Isn't Phabricator trying to do all of this? It seems to get quite a lot of fairly high-profile usage in both enterprise and community-focused/FLOSS contexts.

Re: The Return of Fancy Tools

#132

Post by mytherin »

jcelerier wrote: post #106

> Visual Studio was “disrupted” by Sublime Text and TextMate, no it was not. people didn't migrate from VS to Sublime, they migrated from notepad++ to Sublime. I have never met anyone who stopped using IDEs once they started, except maybe for VSCode with a few hundred plug-ins to reconstruct an IDE piece-wise (but with much less "integration" between the different plug-ins)

Maybe I'm the odd one out, but this describes me to a T. I started programming primarily using Visual Studio on Windows which I used for several years. It has a nice debugger, but the IDE in general was so painfully slow and bloated it actively took me out of my programming flow. I'm also in general not a big fan of all the clicking around that you needed to do in there. Configuring projects using the Visual Studio IDE was a terrible experience for me, and also supremely non-portable.

I moved away from Windows entirely, and switched to Sublime Text in combination with Unix-style tools (lldb, clang-format). Quickly jumping around in files and searching within the project is fantastic, and the editor is supremely responsive. I have since switched to Visual Studio Code, which is slightly slower than Sublime Text but still fast and responsive.

Re: The Return of Fancy Tools

#133

Post by PeterisP »

samat wrote: post #91
chii wrote: post #70

Earlier quoted context omitted.

There's a bias in HN that favours the simple and clean. But the real world is full of bureaucracies and complications due to legacy and/or politics or some other factors (like momentum). When HN users argue that certain tools (like Jira) is too complex, they imagine that a simpler tool following a simpler process would've worked. For them, may be it would, as a greenfield project, but not for the enterprise currently…

Is this complexity warranted? I mean could not the same goals be achieved by less formality and less complexity?

In some cases they could and in some cases they couldn't. For a particular example, in fintech development a bunch of formal ceremonies are non-negotiable, you need to track, document and query who ordered, developed, built and tested what and why and has a change request been formally approved by someone who has the authority to do so. In other cases, the formality is optional, but it's still a choice the organization has made.

However, in any case it's not a technical discussion about tools, that would be putting the cart ahead of the horse, it's about organizational change, which tends to be as slow and difficult as a rewrite of a technical product. If the organization chooses to have a particular process, then they'll switch tools if needed to support that process; and the fact that they could use a more conenient tool if they would choose less formality and less formality does not carry much importance, that choice is determined by other factors.

Re: The Return of Fancy Tools

#134

Post by ZeroGravitas »

Amusingly, the last paragraph is almost the exact opposite conclusion I just typed on another thread, that Ctrl-P type interfaces in Vim is the future of programming UI.

I've struggled with the notetaking issue as well and think the important part isn't the taking notes, but the processes around it. The paper/ink based note systems that work possibly do so because they accidentally force you to refer back to things repeatedly, like the virtual note taking system they use.

I can certainly think of times I've written and then forgotten notes in ink.

Re: The Return of Fancy Tools

#135

Post by dmitriid »

Jolter wrote: post #118
AlotOfReading wrote: post #51

Earlier quoted context omitted.

The biggest issue by far is how slow it is. I don't mean bubble sort slow, I mean deliberately engineered quantum bogosort. A cache-less refresh for me on a blazing fast dev machine takes between 3-10 minutes on a normal day, though it might only take 1m if the internet gods are feeling particularly merciful. That leads to all sorts of avoidance because using it for anything takes long enough to be worth documenting…

I assume your workplace is using the cloud solution? Our huge-enterprise in-house install is blazing fast, as long as nobody misconfigures some automation tool to overload the database. Edit: I did have the bad luck to discover it performs pretty horribly if you’re on a high-latency connection to the office. I think it makes a lot of round-trip requests.

Yes, JIRA Cloud is unusably slow and their "nextgen" rewrite only compounds problems by adding workflows no one asked for and by removing workflows everyone depends on.

Properly configured on-premise installations are usually quite fast.

> I think it makes a lot of round-trip requests.

It does, and that's the main issue

Re: The Return of Fancy Tools

#136

Post by dmitriid »

bradknowles wrote: post #55
greatgoat420 wrote: post #37

Earlier quoted context omitted.

I have never used Jira, could you say more about your feelings towards it? Currently we use an old in-house solution and are thinking of shifting.

Jira is very sensitive to the configuration you build for it, and the hardware it is running on. The full configuration for Jira would make an Encyclopedia look small. Get that wrong (as many places do), and it is hard to use and dead-dog slow, at the best of times. But if you have a real Jira wizard who can configure things correctly, then it can easily be the fastest and easiest way to organize your development and…

> There is a reason why Atlassian is getting rid of Enterprise Jira, because it’s really hard to build a good hardware solution for running Jira properly

And they are replacing it with JIRA Cloud that cannot be configured at all, and is unbearably slow.

Re: The Return of Fancy Tools

#137

Post by alpaca128 »

GeneralTspoon wrote: post #114
toxik wrote: post #112

Earlier quoted context omitted.

I used IDEs and stopped. In fact I wish IDEs would work, that’s how I started with QBASIC and later Visual Basic. But as soon as you step out of playground level programming, IDEs are never on their happy path.

> as soon as you step out of playground level programming Uhh... pretty sure 99% of all complex JVM applications were written using an IDE. In fact, if you joined an experienced team at a senior level and weren’t using IntelliJ, you’d be laughed out of there pretty quickly...

Because writing complex JVM applications without an IDE is painful. That doesn't mean IDEs provide a great experience.

I mostly started with Java in various IDEs. Now I'm using Vim whenever I can, as it's pretty much the only powerful editor that doesn't work against me. IntelliJ is incredibly annoying, e.g. auto-formatting the line I'm still typing, turning my inputs into undefined behaviour. Or telling me a file contains an error but not showing an indicator in which line (of >1000) that error is. But I sure am glad it displays 50 markers on the sidebar to tell me the location of every word in a comment the spellchecker didn't recognise. And to top it all off it switches tabs in some random order instead of the order that's literally displayed on the screen (I don't know why this trend is a thing, I'm not too dumb to rearrange my tabs, thank you very much).

No, Vim isn't perfect. But it's snappy, reliable and most importantly doesn't try to "help" me without asking.

Re: The Return of Fancy Tools

#138

Post by michaelmure »

morelisp wrote: post #110
Izkata wrote: post #105

Earlier quoted context omitted.

Experimenting with distributed issue trackers in git was popular in the early 2010s, there were a whole bunch of different implementations people came up with for git. Most of them died out though, there were typically a few problems - this is what I remember offhand from experimenting with a whole bunch of them: * Some of them make a mess of some part of git; one of them put its info in separate git branches you cou…

> a single issue could be in different statuses depending on which branch you were on To me this is the main point of storing issues in git!

It seems to be a polarizing idea. Many people can't stand it, but also I suspect that very few actually worked with something like that.

In any case, I believe that it's better to build a data model/storage without that concept (read: don't store the data in the same branch as the code) to have the freedom to built it with less constraint and make it right. Once that work you can add this "branch sensitivity" concept on top and again make it exactly how you want it.

An example of problem you get when storing the bug data in normal code branch: cool, you got the bugs state deeply stick with the code so you know exactly when a bug is resolved and in which branch. But now you are stuck with git only to deal with merge conflict, which means you might need to have the user fix it when it goes wrong. Will you push that to a non-technical person as well? Also, what happen when you rebase or cherry-pick?

Re: The Return of Fancy Tools

#139

Post by pydry »

solraph wrote: post #79
jruthers wrote: post #72

Earlier quoted context omitted.

Right. The idea that Jira has been replaced made me laugh. There's probably a crowd of people that want to move on to the next issue tracker flavour and that's fine but I've got work to do that isn't tool shuffling. I'll use the one that integrates with so many of our systems and, though flawed, does a great job.

That integration piece is key. The people who want to replace Atlassian tools usually focus one part of the suite (usually Jira or Confluence), but to replace them you all you need a set of tools that work together. It's not just issue tracking, but alerting, issue management ITSM tools, source control, CI/CD, release management, documentation and I don't know what else that all need talk to each other and provide tr…

I don't think I've ever seen integration between confluence and jira that mattered.

Re: The Return of Fancy Tools

#140

Post by meheleventyone »

john-aj wrote: post #113
noobermin wrote: post #109

Earlier quoted context omitted.

Not to drag on the OP but I really wonder about people who are the subject of these articles who supposedly migrate from x to y to z, because at least for me I'm still using emacs like I did 10 years ago. The things I focus on is more about doing work than what tool I'm using. Do people really migrate or is this more about growth in a user-base? A higher rate of growth of one user-base relative to another user-base i…

Exactly. I'd guess that a majority of VS Code users are relatively new to programming. Not to say that there aren't experienced people who have switched, especially among the TextMate/Sublime Text crowd, but the incredible growth in users? I think that's largely a result of new programmers choosing the same editor, not old programmers switching.

There’s also a big swing of experienced people as well IME. This is partly what drives adoption by new people. There’s a connection there.
Post reply on HN