|
Yes, I've already given a second look at the statement of mine. Why I said that? Well, that is because the application I mentioned here used an HttpRequest to send the email from Gmail servers. That caused a freeze for the WPF UI, until the email was sent.
I used BackgroundWorkers, Tasks, Threads but they all did the same. Never let me do anything while the email was being sent. So, I had to learn these await and async stuff and then it let me work while the email was being sent. That is why I am saying, using these keywords is better, because once the application is loading the resources or downloading them, it won't exit the function it is inside, that is why the UI is frozen. await keyword lets the application to execute other set of commands and procedures when the resource is downloading. That is why, I myself will from now on always prefer the async and await methods.
Thanks anyways, for the reply. If you find any error in my reply, or anything please do reply.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
It depends on my spare time, the current projects I'm on, and the phase of the moon.<br />
Lest yer boss be watching what you post out into the cloud and use it for or against ya in an upcoming performance review.
|
|
|
|
|
Yeah!!
And it applies to most of the people practically.
Whatever the option people choose in survey, this options applies to most of them.
Life is a computer program and everyone is the programmer of his own life.
|
|
|
|
|
I run a small software business and write bespoke systems for all sorts of business - I have no option but to finish what I start, on-time and on-budget. I always go the extra mile to ensure everything is double checked and as bug free as I can make it (even if a project overruns and I have to stand the cost), because remedial work always costs you more in the long run - you win on some and lose on others but ive grown my business steadily year on year for almost 25 yrs now so this works or me, and word of mouth/reputation can be everything - GL all
|
|
|
|
|
Every project I start has two goals:
1. Make a complete and working product
2. Learn something new
I always complete goal #2.
Completing goal #1 is a little more rare. Usually, after I've learned what I could I get bored implementing the details, shelve the project to get back to "later".
|
|
|
|
|
Exactly,
The definition of finishing is "interesting" here...
I don't start NEARLY as many projects as I used to. But I now admit that I will create something for the sake of learning. Once the learning phase is over, I don't care to "finish" (and support) a full project for it.
An example. I have a wonderful outlining tool for Windows. Would love it to work on the Mac and on the iPad. I have been thinking about implementing an HTML5/Javascript and Node.js in order to learn Node.js... Not sure if I would publish it when I got it working... That last 10% of polish takes 90% of the time!
|
|
|
|
|
I always finish everything I s
PooperPig - Coming Soon
|
|
|
|
|
I too always finish everyt
|
|
|
|
|
Your time will come, if you let it be right.
|
|
|
|
|
Well, I always finish too, but also almost always have to learn 'not from Finland', even though I already know.........................
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
eXtensible
Project
Definition
EOF
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Finished is when the scope of the work quoted has been met.
But we secretly hope there never finished so the customer buys more hours
[EDIT]
So I guess finished is when the customer stops spending money on it.
|
|
|
|
|
jkirkerx wrote: when the customer stops spending money on it
Ah, yes, there is that -- when you get laid off for lack of work.
|
|
|
|
|
Finished is whatever you feel "finished" means. Everything can always have more work put into it, but there's a point where you're taking something that's finished up to some difficult-to-pin-down point and making it a new version of the previous iteration.
Finished, to me, means it's at the point where it can go out into the wild without adult supervision.
cheers
Chris Maunder
|
|
|
|
|
oh!
I didn't think of it like that.
So finished perhaps may be when the customer or user of the software are happy users, with no complaints, and I can go to Vegas for the weekend knowing that it's finished.
Thanks Chris, makes sense if I got it right.
|
|
|
|
|
>So finished perhaps may be when the customer or user of the software are happy users, with no complaints, and I can go to Vegas for the weekend knowing that it's finished.
That's maturing or dare I say retiring. Finish is when the project met your initial expected goal for that phase. For example, it may be only half way into the project but that's your milestone goal.
|
|
|
|
|
"Finished" simply means that I'm not going to work on it any further.
I have plenty of personal projects that I started and could work on, but I'm no longer interested in doing so.
|
|
|
|
|
There's a fine line between "finished" and "abandoned".
Finished, I guess, is in the eye of the beholder.
cheers
Chris Maunder
|
|
|
|
|
"All required functionality is functional. Some functional functionality may no longer be required."
|
|
|
|
|
I finish almost all of my projects, for work.
I have a tendancy to finish some of my projects, for play.
|
|
|
|
|
I work in the industrial field, we don't really have deployed products.
We have a standard software that may be customized for each and every customer (gods bless the ones who like the standard) and mantained. This means that for every standard version we deployed there are several branches of customization trees, some many of which incompatible with each other.
So my job consists in: making quick customizations (button positions, colors, log lines...), making deep customization (entirely new algorithms that work only on a specific product...), improving the standard software generalizing successful customization, adding required functionalities or refactoring for performance, and finally bugfixes.
Having thousands of customers worldwide and being only two people working on the software, finishing something is a luxury.
|
|
|
|
|
If finish means really Done, deployed, never touch it again... no, never worked on a project like that.
I've been always involved in products so they never actually finish.
So for me the concept of finish is when you reach a point when you have more maintenance tasks than actually new developments.
Usually when I reach this phase (or a bit before) it's time to move on.
My concept is to help give birth to the "child", see it do its first steps and move on to make a new one
|
|
|
|
|
To me "finished" doesn't mean putting out the project to pasture and never see it again. It means I've achieved what I was setting to do for that phase of the project. Whatever you called them: goal, deadline, milestone, expectation, etc. Once it reaches that point, it is finished.
|
|
|
|
|
My open-source projects/articles are a form of A-B test. I can't know in advance what is or is not useful so I put stuff out there and, if it gets a lot of interest, I work on it.
However this does require letting things go as a "sunk cost" if they don't.
|
|
|
|
|
I have trouble starting most projects!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|