|
I retired for a couple of years, then applied to a local firm as a VBA "Developer" (quotes mine). The intention was to take it easy but still have an income to pay for my love of travel.
Once they found out I used to work in IT and was quite handy with SQL, I ended up with more and more "technical" stuff. Now I'm in a small, multi-skilled business-side team that advises on Process Improvement, RPA Automation, Insights & MI as well best use of Office tools, Power suite and general geekiness I did manage to get SSMS installed - probably because it's free - but long gone are the days of being able to knock something up in C#. Can't even use any of the scripting languages as I'm not on the white list
|
|
|
|
|
Redmine is a solution to all the features you ask for.
It is open source can be run out of a Docker container, onsite, for a 'free' option.
|
|
|
|
|
Git commits?
We use asana for tasks, and we add subtasks and comments along the way. New issues get added to the product backlog section and tags get added for priority. As a task is picked up, the person doing the work assigns the task to him/herself, and others may be added as collaborators or assigned to subtasks within the main task. It's simple and searchable.
|
|
|
|
|
I use Excel, It works for me. simple to use, reliable.....
Just create the columns you want, mine starts with the date. the rest is easy.
ed
|
|
|
|
|
|
I use a product I developed for a client some years ago. Admittedly, it needs some updating, but it covers the basic things you want to do. You can look at the product and download a demo at Lucid Help Desk[^]
There is a client-server version available, which is not listed in the purchase page.
|
|
|
|
|
We wrote our own app to do that. You get just what you want that way. But, I think that there are open source help desk apps available.
|
|
|
|
|
Our IT uses Roundup[^] to track it's own internal issues. Small footprint, easy to use, easy to maintain. We don't use any integration, but it is possible[^]
|
|
|
|
|
How about a big honkin' Excel spreadsheet sitting in a shared network folder on Fred's laptop?
[whistles and wanders quietly away]
Software Zen: delete this;
|
|
|
|
|
Hello,
I can recommend redmine.
https://www.redmine.org
I have used it for years as a free install on a local linux box. Stores its data within PostgreSQL, MySQL or MariaDB. Links/integrates to various source control programs. I have it linked to svn and git. So you can see the check ins against the tickets. And review the changes without ever leaving redmine.
There are hosts for it too, though i've never used them so can't suggest one.
Hope that helps.
Cheerio
|
|
|
|
|
|
(So my time machine works then. Excellent.)
|
|
|
|
|
You should already know that!
|
|
|
|
|
Not clickbait. Patient Zero.
|
|
|
|
|
Shouldn't that be "Patient minus one hundred and forty-nine million, nine hundred and ninety-nine thousand, nine hundred and ninety eight"?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: 150 million years later, and they spot a fatal disease. I'm impressed! Dinosaur NHS at its finest, no doubt!
Keep Calm and Carry On
|
|
|
|
|
They always show volcanoes. It was the smog.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
This critter was dug up in the states - so no NHS. Maybe COBRA, depending on when it planned to retire? Too young for Medicare.
|
|
|
|
|
craig robbins MN wrote: This critter was dug up in the states - so no NHS
But it lived long before the US declared its independence.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Is that the first diagnosed case of bird flu?
|
|
|
|
|
0) We don't use branching/merging in TFS.
1) We don't have a configuration manager that should be in charge of making deployment packages.
2) We never get sanctioned time to work technical debt on our 13-year-old code base
3) We never get sanctioned time to work on developing tools that help us do our jobs better (a different kind of
technical debt)
4) It's not a software development management tool, it's a people/time management tool that doesn't allow for mistakes or problems, or delays outside the development process (usually regarding infrastructure problems).
5) Our program manager is micro-managing our development. Yesterday, he had an all-day meeting to go over ALL of the support tickets and what their status was, and he took it on himself to cancel a bunch for reasons only known to him. During the meeting, he said, "What are you guys doing with your time?", and I said, "Well right now, we're in an endless meeting listening to you complain about ticket statuses, when we could be working on the tickets we've already been assigned." That response was not well-received.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: 0) We don't use branching/merging in TFS.
Branching/merging is a process smell.
In thirty years (?!) of development I haven't had to use branching/merging.
#realJSOP wrote: 3) ... to work on developing tools that help us do our jobs better
TFS' API is an outstanding tool for developing these kinds of team-helpers.
|
|
|
|
|
PIEBALDconsult wrote: Branching/merging is a process smell.
In thirty years (?!) of development I haven't had to use branching/merging.
Attempting a discussion, not a rant nor anything to prove.
In a team, Branching, Merging means:
1) Production-running code is on the Main (develop, default,etc.) branch.
2) To make a change, a developer branches Main (production code), makes changes, enhancement, bug fixes --- This leaves Main (prod code) safe and sound in it's original branch.
2a) Once dev is done, code is built & handed to QA/Test
2b) Maybe QA/Test notice some things that have to be fixed in the code.
2c) Dev makes more changes (checking into branch along the way, of course) and submits to QA/Test
3) Finally the code is approved.
4) Merge the changes into Main (default, develop,) branch and deploy.
* This all means that Production code is always safe and easily retrieved from Main branch
* This means that if a dev begins doing a change and it is decided not to be used then the branch is dead & she doesn't have to pull the code out of Main (production code).
* This also means that a team of developers can work on different parts of the system at the same time (last to complete & merge to Main gets the pain though).
* Keeps things so you always have a good working copy in source control at all times.
Does this still seem like a Smell?
Just curious.
|
|
|
|
|
Quote: Branching/merging is a process smell. Disagree. There should be a release branch for each previous release, plus a development branch. Only bugs are fixed in a release branch (and damn the architecture). They must then be fixed properly in the development branch, which is also where new features are undergoing development.
modified 10-Feb-22 14:47pm.
|
|
|
|