Sander Rossel wrote:

Yes always, there's a very good chance that user uses this password everywhere. If you know their password you could probably login to their Facebook, Google, Instagram and bank accounts. If someone hacks your database and the passwords are not sufficiently secured (and personally I think anything less than a strong hash is not sufficient), those hackers can now login to those accounts too. And if those hackers post everything online, everyone can login to those accounts. It doesn't matter what data a password secures, the password in itself is private and VERY SENSITIVE data. In a perfect world it would be some "unhackable" randomly generated string of at least 24 characters, but we're living in a world where 123456 is still the most used password.

It's actually far worse than that... the users don't even get to choose their own passwords. They are assigned by IT (Not a policy I approve of or had any hand in), so the chances of that password being reused elsewhere is very slim, unless this might be the first password they ever use and they then decide to use it everywhere. But honestly, what's the chances. Edit: Forgot to add that surprisingly enough, these password are quite strong passwords with no pattern on how they are created... not 24 char random strings, but at least decent enough to keep most at bay I would say. For example, Ap@rtmentDataC0nnect10n was one memorable one I saw (relax...no longer in use ;P ;) )

Sander Rossel wrote:

Schedule a call with the user, add boatloads of logging, get only that part what you need from the production database (preferably from a "privileged" individual who has rights to that database).

Did that before too when working with a client where impersonation was not possible. Sometimes the effort and time involved in getting multiple cycles of changes deployed to a production environment just to debug a problem is not realistic or in the client's best interests. BTW, when I say impersonation, I am by no means advocating something like a button allowing ordinary or even support staff to impersonate someone. I mean impersonation by somebody that in any case has full access to the entire production database(s) and code base. Typically the most senior 2 or 3 devs/architects/whatever on the team would be my exception here, and as you say, only when the system does not store sensitive personal information. <

This brings up an interesting debate I have had with some management members of a corp I do software development for. If the software belongs to the corp, and the person using it is an employee of said corp, and the software is only used for business related data... is it really an invasion of privacy to 1) know their password? or 2) impersonate their user for debugging purposes? I honestly don't have an opinion on this. I have seen both sides of the argument... a case where the problem ONLY came up for that one single user and couldn't be duplicated in any other way... and a case where somebody maliciously used their ability to impersonate a user to get said user into trouble. I guess as with many things in life, good judgement on need and urgency are better than absolute policy.

As had been echoed by many in the replies, I simply use the built-in Windows Defender and have been since circa the Windows 7 days. It just works, stays out of the way, and has no (or very very little) noticeable impact on performance. I have been recommending it to users for many years, and have had zero complaints from those that took my advice. I wish I could say the same for the variety of paid for AV software on the market :-(

This is a question I asked myself recently when a client requested this new fangled PWA nonsense :doh: . What does it actually mean, and why would you want it. Turns out, it's actually pretty cool :omg: and let's you do all kinds of stuff like support your webapp working while it's offline or in bad network reception, push messaging, camera and location access, etc. Of course, these technologies are not called PWA, but they fall under the PWA umbrella, ie, Progressively support advanced features without requiring them for your app to work. Where the term then comes from is you write a web app, and then add stuff like offline caching, location awareness, media access in such a way that the app works to some degree at least even if the browser it's viewed from doesn't support those features. Check out Google's work on this for some excellent examples and explanation (with a top notch framework to boot) Google Workbox

What surprises me most about this thread is the clear split between people that seem to feel the dev was perfectly within his rights, and the people that think he was rude. Nobody seems to be somewhere in the middle. First of let me say that when it comes to Open Source I agree that if a bug bothers you, or a feature is missing, it is foremost our responsibility as developers to rather assist and implement it than file a bug report about it. The issues page is for users. But sometimes, even us developers are just users, so we want to use software without having to write it first... and that's perfectly fine too. I can't be a contributor to every open source software package I use! :omg: I would never be able to do anything for myself. And that's the case with you Bill I think... in this case, you are just trying to be a user. And what happened is you got treated like a user by the developer. As for the devs reply, I think the first part was perfectly polite and understandable. The second part is rather snarky though, and very dismissive. Perhaps it was just frustration at this issue being reported "again", or perhaps he is just an idiot. :rolleyes:

That was excellent. Thanks :-)

Marc Clifton wrote:

I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository."

I think, as other have mentioned, this is where the problem lies. 'commit' and 'checkout' still mean the same thing as in SVN, it's just that you are working with a local repository, instead of the remote one. I have been using SubVersion for years, both at work and for my personal projects. I signed up for a GitHub account a while ago to check what all the fuss was about, and never really started using it. It was too complex and confusing. I felt just like you do ;) Recently, I started collaborating on another project which was hosted on GitHub. This forced me to learn the mechanics of Git. Took me quite a while, and I still have the Git Book[^] open in a browser window whenever I need to do anything more than a local commit, but I am starting to see the advantages... especially for multi-developer projects. Not sure if I would use it for solo projects, but then again unless I know I am never going to make this code available to anyone else, I might as well use something where I can easily manage outside contributions.

Why not just ntt? If you spell it out (which is what I assume you should do if there are no vowels :doh: ) its en-tee-tee... Sounds about right to me ;P

loctrice wrote:

It's not quite the same thing.
It's more like the guys at the mechanic shop saying they can't air brush the image you asked for onto your car, or repair the body because both of those require specialists. Very very few mechanic shops can do that.
There are plenty of mechanic shops that can replace a transmition, but not rebuild it. To rebuild it, you would need someone who knows that particular specialty.
Also like the oil change people saying they can't change the exhaust manifold and give you a new exhaust system.

Well, didn't address what I said at all, but OK... What I said is that the mechanic should at the very least know what went wrong, in other words, my transmission blew. Not that he should be able to rebuild it. Of course that is a specialty, just as configuring server hardware, or setting up Storage Area Networks, or migrating Active Directory is a specialty. You are saying that solving a driver problem is a specialty, when in fact any IT Tech with 3 months experience could do it.

loctrice wrote:

I don't think the ability to trouble shoot the OS has anything to do with writing software, unless the os's code is available to look at.

Apparently, our opinion differs ;)

loctrice wrote:

BSOD ... doesn't happen to me , I use Linux. If it happens at work, I'm completely lost.

So let's not confuse the issue of being able, and lack of interest. As a Linux user, you have no interest in Windows problems. And most Windows users couldn't care less if your WiFi driver for your new laptop doesn't work in Linux. I use both, and run servers on both. Each has its place, its purpose and its flaws. I know how to trace problems on both, and know how to code for both platforms.

loctrice wrote:

unless the os's code is available to look at.

And Linux kernel source being available to look at hardly helps to debug a driver problem. Maybe for the guy that wrote it, but definitely not for the user. Error messages + Google = Happy computing. Try it :laugh:

loctrice wrote:

Computer User:
------------------------------------------------------------------------------
a person who uses computers for work or entertainment or communication or business

I assume you made the User and the work parts bold to empasize and try to point out that programmers are as a matter of fact users just doing their work. That's like saying a mechanic is just another car owner because he drives a car to work. It's true, BUT, if his car broke down on the way to work, it's kinda logical to assume he would maybe know how to fix it. Or at least have a good idea what went wrong even if he can't fix it himself. Programmers that complain about BSOD and PC's malfunctioning are like the mechanic that can't even tell you what's wrong with his own car. Would you trust that mechanic to fix YOUR car...... I didn't think so! So why should I trust that kind of programmer to write decent software?!? :confused:

Mark Nischalke wrote:

Most automobiles have many computerized systems in them. Do you expect the mechanic to be a computer technician?

Yes, as a matter of fact, I do. In at least so far that he knows how to run a diagnostic on those computerized system. If he can't do that, then he isn't qualified to work on my car, and he should stick to fixing VW's ;)

Mark Nischalke wrote:

Do you expect them to be a materials engineer to determine why the brake pads have worn out?

No, but I do expect him to be able to tell me that the brake pads are indeed worn out, not just simply "Uh, your car won't stop.... I don't know why!"

Mark Nischalke wrote:

So you expect anyone who programs computers to also be a hardware technician?

So, by definition, a programmer is someone who makes a computer system do his bidding. Whether it be via a provided API, or direct to metal, makes no difference. If something goes wrong, I expect them to be able to find the problem, even if it turns out that the problem lies in the API... ie, if a "programmer" ever came to me and said "It doesn't work... I don't know why!", he loses all credibility in my eyes In short, I don't expect the programmer to fix the hardware issue, or the driver issue either. Just to be able to point to it, and say "This is what is causing the problem... Can you help me fix it?"

I agree... I have also written myself plenty of utility libraries over the years writing desktop applications, server software and web applications. The simple reason why... I want a way that works similar over all my enviroments, and one that *I* can debug if something seems to be going wrong... Or the newest release of PostgreSQL rolls around and they decide implicit casting is evil again :sigh: So yes, I have written my own abstractions because they work the way I think, not the other way around ;P

Luc Pattyn wrote:

My mistake. You're right about the test, if it sits on the top of the method, it gets executed twice so it can't go wrong. However executing it twice all the time may be a high price to pay for potentially saving one thread switch when the form closes.

Hey, no problem. I make mistakes all the time. Hence my motto There are two ways to write bug free software. Only the third method works though ;P As for the performance cost argument, I think it's highly dependent on the scenario.

Luc Pattyn wrote:

I do not really agree on the BeginInvoke issue.

I agree with you. In a large project or any other production level code, things should be done consistently, and all the things you mention are true. That is why I stated that in this simplified scenario, BeginInvoke doesn't really matter. If the function was even remotely more complex, or had more than 3 lines to execute with the synchronous vs. asynchronous path, it would be far more important. Glad we could agree :)

In fact, it doesn't make a difference. Common misunderstanding. Let me first put in the code snippet

public void SetProgressValue(int value)
{
if( formClosed == true )
{
return;
}

if (this.InvokeRequired)
{
   ProgressValueDelegate pvd = new ProgressValueDelegate(SetProgressValue);                
   this.Invoke(pvd, new object\[\] { value });
}
else
{
    m\_progressBar.Value = value;
}

}

When SetProgressValue is called from another thread, the first thing that happens is the check if the form is closed already. Let's take you hypothetical situation where a FormClosing event is queued, but has not been executed yet. formClosed is false, so now this.InvokeRequired is checked. It's true so a call to SetProgressValue is queued as well. The FormClosing event fires, and formClosed is set to true. Next, the queued call to SetProgressValue occurs. First thing, we check formClosed which is now true, so the function is terminated immediately. The common misconception is that Invoke simply transfers the call to the correct thread, but in fact the function is called all over again. Another thing many people are not aware of is that the call to Invoke actually halts the thread until the Invoked delegate has been executed in the GUI thread, which can cause major slowdowns. Rather use BeginInvoke. It does the same thing in this scenario, but does not block the calling thread.

I have had a similar problem many times. In a lot of my apps, I have a textbox that sits on a form, and any thread can write a line to it. I have poured over documentation, and never found a solution to whether the form has been closed or not. So, I simply added the following :

private volatile bool formClosed = false;

private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
formClosed = true;
}

delegate void ProgressValueDelegate(int value);
public void SetProgressValue(int value)
{
if (this.InvokeRequired)
{
ProgressValueDelegate pvd = new ProgressValueDelegate(SetProgressValue);
this.Invoke(pvd, new object[] { value });
}
else
{
if( formClosed == false )
{
m_progressBar.Value = value;
}
}
}

BTW, you can also move the if to before the if (this.InvokeRequired) to save yourself an Invoke call if it won't be doing anything in anycase.

Not to bring it up again, load Gentoo, and use bash + bash-completion. Configurable, extendable command-line parameter completion for any program that a template can be coded for. BTW, I (heart) Gentoo ;P

Same points as most of the people above. I have been using it at work, on desktop and laptop, at home on my desktop and my entertainment PC, and have a few friends working on it as well. If you have a 1Gb+ machine, and a relatively recent GFX card, Vista is way better than XP. It crashes far less, uses memory much more effectively, and in my experience, Disk I/O is also much faster than XP. For some of the comments regarding XP on a older machine. I had a dual-boot setup of XP and Vista on my home desktop for a long time, and ended up in Vista 95% of the time. Also has VS installed in both, and VS started up much faster and was much more responsive in Vista. On the down side, the interface takes some getting used to, and I really don't like the minimalist Explorer UI, or the fact that you always need to find a unused area to right-click and "New->Folder", but that's more habit problems rather than OS problems :doh: Overall, I wouldn't go back to XP for any reason, except if I got a very old machine

Considering that I myself have programmed in virtually every language that any poster has mentioned, I would personally also recommend C# I have personally watched many a potentially brilliant programmer become useless because they were taught with VB. Not saying there is anything wrong with VB. I think it's a great language actually, but not for learning... Let me explain 1) Case insensitivity - This is the biggest problem with this language. It makes programmers lazy. Period. :( Once they have gotten use to not having to type in the correct case, any chances of them ever moving on to another language is lost. 2) Not having to declare variables - I have this same gripe with Java. Once you get into the habit of not declaring your variables, you get into the habit of forgetting that your data is actually represented in a certain way on the PC, and then you learn even less of how your computer actually works. 3) Syntax lessness - I know that's not a word, but you know what I mean. The semi-colon in coding is a big thing. And if it wasn't, the most used languages in the world would have gotten rid of it already a long time ago. I have had many a VB programmer give up on learning other languages because they had to put a semi-colon at the end of statements. In short, I recommend C#(or a C based language) simply because it teaches good programming practices. After that, any programming language is good, because you understand whats going on. I myself do programming in PHP, Java, and VB on a regular basis for work projects, and they are perfect for some of the projects, so nobody has to jump down my throat that I am bad mouthing VB,(insert other language of choice...) Just my 0.02c ;P

1. is the logical answer... Why do you ask? ;P

Pete O`Hanlon wrote:

Pretty animation though. Gives me something to shout at.

Yeah, and I do a lot of shouting at it. It's my only problem with Vista, like many others have said, but I find it extremely irritating. Also, on the same copy speed note, I have noticed that copying a large amount of small files to a USB memory stick takes forever. And by forever, I mean "100 files totalling 1.5Mb taking 5 mins". At first I thought it was my memory stick, but exactly the same operation under XP on another computer finishes up in a matter of seconds. Also, the update they released did nothing to fix it in my opinion... Large files are now better, but lots of small ones are still just as bad. PLEASE let this be fixed :sigh: