|
|
Go-live was less than ideal (actually quite rough) and there were some pretty upset customers, lots of phone calls from them to upper management. Some didn't have data for over 2 weeks and had to use fall-back systems. Not our (developers) fault though, the issues were on the EDI side, so data wasn't coming into the system. But things were fixed and we managed to get the project up and running  I'm no longer working there, but I've heard that it has stabilized, although there are still a few issues, which will get fixed.
Now I'm at a new job (started in May) and I miss (parts of) my old job, the irony  Maybe I was a bit hasty in leaving, but I was pretty frustrated at the time. I have a lot more admin to deal with now and more pressure for deadlines due to the nature of the projects (fixed cost & timeline), but at least the development work on the current project is interesting and I've learned a lot of interesting new things.
modified 2-Jul-21 1:24am.
|
|
|
|
|
I just downloaded MPLab X IDE [^] and I was using it when -- I'm not kidding here -- a subconscious thought began rising like a whisper "win95...win95..."
Then, it hit me. The app is a Java-based desktop app and all of the controls, navbar, etc. look strikingly like Win95 UI. I had a bit of a nostalgic moment and it made me laugh.
Java desktop UX/UI never really moved past Win95, I guess.
Fact is stranger than truth. 
|
|
|
|
|
|
Thanks for the tip. I've used that package on my win10 computer (laptop), but in this case I was installing on my desktop (Linux) and unfortunately there's no linux installation for microchip studio. I was just trying to see if I could use mplab to do the same things but the two are really quite different (as you probably know). Thanks again.
|
|
|
|
|
Not a problem.
Yeah they are quite different.
The less you need, the more you have.
Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?
JaxCoder.com
|
|
|
|
|
Still, having to work with Cypress PSoC Creator ('The worst IDE in the World'), I desperately miss the MPLAB X IDE. 
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
raddevus wrote: Java desktop UX/UI never really moved past Win95, I guess.
If only Microsoft would go back to a ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) ing simple interface too, with a single Control Panel and no clutter on the screen.
It would save me the hassle of installing ClassicShell and would work better.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
if (foo)
{
DoSomething();
}
or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
}
}
eh?
|
|
|
|
|
Depends on context. Can you not avoid the if entirely? Is that called in a tight loop?
As presented, I'd stick with the first example.
|
|
|
|
|
Well, maybe this is a trick question, but ...
I read and understood the first one immediately.
About as quickly as I read it.
The second one...I'm still not exactly sure about it.
I guess it's all a state of mind.
If you like objective, try #1.
If you like subjective, try #2.
|
|
|
|
|
second one.
reduces the amount of potential if statements to just one.
first one is easier to understand and read, I admit.
|
|
|
|
|
The first
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
I would normally use (1), but if there were many such usages, I might consider (2).
The advantage of (2) is that if it turns out that the conditional must be modified, it only need be done in one place:
Marc Clifton wrote:
MaybeDoSomething(foo);
...
void MaybeDoSomething(bool foo)
{
if (foo)
{
}
}
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
foo ? DoSomething() : ;
Simpler is better!
|
|
|
|
|
This isn't the obfuscated C contest, and there is no prize for using the minimal number of keystrokes.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Obfuscated is when you use partial template specialization for the task!
|
|
|
|
|
it wasn't me, i swear!
*hides*
Real programmers use butterflies
|
|
|
|
|
|
Not a fan of the second form. If the condition was something else, sure. But otherwise I say: the shorter a boolean lives, the better. Ideally they don't even become "reified": just an ephemeral condition that is used immediately when created, never stored in a variable. Boolean variables are a plague.
|
|
|
|
|
I prefer the former, why make the call if there's a problem?
The less you need, the more you have.
Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?
JaxCoder.com
|
|
|
|
|
What if (no pun intended), the "if" actually required more complex logic, including perhaps some nested stuff, like:
if (foo != null)
{
var data = GetSomeData(foo.SomeValue);
if (data has some specific value/s)
{
DoSomething();
}
}
From an aesthetic point of view, I dislike putting all that into the main method, hence why I've got a couple "Maybe..." methods because the above scenario matches in pseudo-code what I'm actually having to deal with.
|
|
|
|
|
True there are always exceptions but for the simple example you gave I still prefer the former for the less complicated logic.
The less you need, the more you have.
Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?
JaxCoder.com
|
|
|
|
|
Marc Clifton wrote: What if (no pun intended), the "if" actually required more complex logic, including perhaps some nested stuff
This is a different question. The original question is very simplistic.
If we were discussing a real scenario, I'd ask what is the conditional logic, how many times will it be repeated and in what context(s), how large is the function in which it's called, etc.
But for this simplistic scenario, I'd use #1 because it is not efficient -- either in coding and probably execution -- to call a function for no useful reason.
|
|
|
|
|
If the test is complex and gets used more than once, there's an argument for giving the test its own method. That way the test is isolated, and can be changed later, but it's not hidden away in the MaybeDoSomething method. So you might end up with
if (TestIfWeNeedToDoSomething( ... ))
{
DoSomething();
}
// lots of code follows.
if (TestIfWeNeedToDoSomething( ... )) // again
{
DoSomething();
}
and so on. A little inelegant, though.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
