|
|
V.funny and the fact that a few exist in our office.
The best way to make your dreams come true is to wake up.
Paul Valery
|
|
|
|
|
While still having reservations, I will give MS some credit...
I reported a suspicious/misleading package "Newtonsoft.json.dll" as opposed to "Newtonsoft.json", and it was gone in a few hours. Obviously, having realised it was not the real thing I never downloaded it to check, but hat's off to MS for the quick response.
(It had already had a few thousand downloads by then - hopefully not too damaging)
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I noticed your rant about NuGet yesterday. I use NuGet frequently, but only to install some packages from its command line. It always worked 100% for me. Maybe I was just lucky?
Get me coffee and no one gets hurt!
|
|
|
|
|
I have never had any issues with Nuget in regards to security, etc.
We use NuGet for all of our assemblies and we have an in-house NuGet server for our own assemblies. When used properly, NuGet is quite awesome and useful.
If you have reservations about NuGet, then that is your problem, and your problem alone, because our software shop and thousands of other shops do not suffer from that ailment. 
|
|
|
|
|
Did your crystal ball show you that ?
«Beauty is in the eye of the beholder, and it may be necessary from time to time to give a stupid or misinformed beholder a black eye.» Miss Piggy
|
|
|
|
|
Yes. I take all life instructions from my crystal ball. 
|
|
|
|
|
Slacker007 wrote: Yes. I take all life instructions from my crystal ball.
Does it make you walk funny? And what happened to the other one?
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
A small one to finish the week
Fast love and the big smoke (8)
Enjoy
modified 23-Jun-17 4:12am.
|
|
|
|
|
Velocity
Anag of love = Velo
Big smoke = city
|
|
|
|
|
Well done.
And your prize is...
Your turn monday 
|
|
|
|
|
ermm.... yay, I guess ? 
|
|
|
|
|
Second prize is two goes on Monday!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Just happened to me.
Just spend 2 weeks rewriting complicated code that no one understand into a simpler form.
They all agree that my code was simple. But didn't agree that it is the same thing as the old code. Not because they see any difference, just one the ground it couldn't be related since they didn't understand the previous version.
End of story we don't have time or resource to replace the code. Change goes to the bin....
I forgot to mention. There is a serious problem with the old version that my new version solve. I guess the problem will just remain.., I guess we can talk about it again when the problem becomes very pressing....
[LATER EDIT]
1. my political skills are rather weak.
2. the tech lead surprised me in a nice way, a bit later about that.(basically told me to wait a bit and introduce the change gradually)
modified 23-Jun-17 3:27am.
|
|
|
|
|
Super Lloyd wrote: Change goes to the bin....
Keep a copy, when the problem is very pressing... say you have to retire and think about it, take 3 off days, come back with your solution, deploy it directly, prove that the problem is gone, ask for a rise.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I guess they've never heard of testing / acceptance criteria?
|
|
|
|
|
no time for testing!
I should have stressed that 1 advantage of my new classes is that they are much easier to test. Being in a standalone library, as opposed to inextricably spaghetified inside the app...
|
|
|
|
|
Super Lloyd wrote: Being in a standalone library,
It only took you two weeks to refactor this code, there are no unit tests and your solution involved putting it into its own library?
Just saying those factors would scream high risk to me.
|
|
|
|
|
On the other hand they claim they want automated unit test on each part of the application.
I just did that for one part. The one that interested me. And also solved a long standing bug for it.
But I am not too worry. We will the long standing bug unsolved. We might spend a few more weeks looking helplessly after it. A solution might be direly needed one day.
Meanwhile I will extend my test app with more automated test as I need them. Until people find it attractive enough. And by app I mean my component library which is really not big a deal to plug in the current app.
|
|
|
|
|
Additionally the only guy who understand that code (he wrote it)
- agrees with me that the intended behavior is relatively simple
- loves my new implementation that is a simple as it should
- I involved him like 10 times a day everyday
- agree with me that updating the app with this is trivial
- love the fact that this code is finally simple and easily testable independantly and automatically.
Now I agree why change anything if it's not broken?
Well, it is broken unfortunately...
and someone who don't understand the current code is afraid that replacing it with my new code is going to be very risky. By this account nothing should ever be done.
|
|
|
|
|
If you don't know what the code does, how can you know you tested all important aspects of it?
If they had tests up front that test all the important behaviors, then the replacement code just needs to pass to give them the confidence to deploy, but obviously, they don't.
|
|
|
|
|
Ah yes - keeping all the code smells in place - a skunk cost fallacy.
|
|
|
|
|
I did that once.
I rewrote a complete application based only on the old code.
I didn't know what it did or how it worked, only that it did something with stocks.
A coworker who didn't know what it did or how it worked either (manually) tested the code (we had no unit tests, documentation, or anything  ).
The reason I had to rewrite it is because this application kept giving problems and no one was able to fix it (or a fix introduced new issues).
So two days work and we released the app to production (Acceptance testing? Hah! We don't need no stinkin' acceptance testing ).
And all of a sudden they got a stock of -100000
After a bit of investigating the issue it turned out that I forgot a single if statement 
The issue was resolved rather quick, they manually adjusted their stock (which they did once a month anyway) and we sent them a pie for the inconvenience.
After that we never had problems with that app again (so kudo's to me I guess) 
|
|
|
|
|
Can you capture or extract inputs+results of actual production usage on the old code?
Get a month or two of transactions from the old code.
Replay it on the new code and verify that they produce identical results.
(Keep the inputs/outputs for future Unit Testing/Regression Testing of the new code)
|
|
|
|
|
This is for an app which controller multiple hardware pieces. I only rewrite a controller for 1 piece.
They don't have automated test, only manual tests which takes ages apparently...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
