|
GuyThiebaut wrote: Yes, yes, yes... but is the icon going to change? All of 'em will be changed again!
Busy and productive times lie ahead for the great creative minds at microsoft!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Firefox will start switching browser users to Cloudflare's encrypted-DNS service today and roll out the change across the United States in the coming weeks. Now, no one will know I'm visiting 76.74.234.210!
Sadly, US-only for the moment, but fingers crossed.
|
|
|
|
|
Kent Sharkey wrote: US-only for the moment
By default. You can still turn it on manually in other countries.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
So that's why FF is going so damn slow since last update?
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 understand that in Canada, Trudeau will personally route all internet traffic.
|
|
|
|
|
And apologize for it.
TTFN - Kent
|
|
|
|
|
Last week, an email popped into my mailbox with a simple subject: "Jif vs. GIF." Its sender asked if I was interested in hearing about a peanut butter producer's interest in "setting the record straight on how to pronounce GIF." Everyone knows it's pronounced 'GIF'
|
|
|
|
|
"Graphics Interchange Format", so not "Jraphics Interchange Format". Simple.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
It's pronounced, Ob-se-leet
|
|
|
|
|
No-one should need more than 256 colours!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Tech companies are famous for having some of the world's most challenging and competitive interview processes. Almost as far apart as I'd like to be from the interviewer?
Or can I hang the interviewer from the cable?
No interviewers were harmed in the posting of this blurb.
|
|
|
|
|
You don't need to be a maths-professor to understand MSDN. Being good at maths (abstractions) was good advice in 1970 if you wanted to go into "computing".
Nowadays, patience and perseverence gets you were maths can't.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Understanding algoithmic complexity can be very useful though.
Once I was asked to code a task a certain way and instead proved that if we adopted that approach everyone involved would be long dead by the time the task completed.
After that I was given free rein to write the task correctly.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Was the solution "42"?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Either the correct answer is "I would Google how to solve catenary problems", or I'd end the interview as a waste of time. Learning a customers domain knowledge is part of my job requirements; being an expert in whatever esoteric stuff they're doing prior to start is not.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
A question in a job interview I had time ago was like "do you know how to...?"
My answer: "No, I never had to do this before, but if I get the job I will learn how to do it faster than other competitors"
I was lucky, the boss of the department had common sense and liked my answer.
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.
|
|
|
|
|
When development is iterative and Agile, testers need to be embedded with the developers and work closely with them. Someone's got to clean up
|
|
|
|
|
If you plan less, you better test more
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
Testers who work closesly with developers tend to think the same way as the developers. So they test what works. Not that which doesn't work.
There is the "5yo test": Start the program, set your 5yo on a chair front of the screen/keyboard, and tell "Every time you can make the program crash, and show daddy how you did it, you'll have an ice cream cone". That is sort of the junior version of the ideal tester.
In one company, we hired students as testers (of end user GUI applications) on half year contracts. After half a year, they had learned the "right" way to do things, and their reporting rate had dropped considerably. When a new crop of testers came in, we had a whole bunch of new reports, for a few months, and then they had to be replaced.
In my current company, we made an explicit decision to take the testers out of the development group, to form a separate test team. Developers still write module tests (for use by the test team), but all higher level tests are made by the test team. The test team does not touch the source code (they rarely even look at it); if an issue is detected, it is reported to the developers to fix. Essentially, the test team is responsible for maintaining a 99% automated test framework that is run on every nightly build. It wouldn't be realistic to handle issues any faster than the next morning anyway. We have much greater benefit from testers being indepent of the developers.
|
|
|
|
|
Very similar to my experience with respect to an independent test team.
|
|
|
|
|
I see the advantage of separating the testers from the developers. However, the testers and the developers must still share a location. There are too many cases where the testing has been outsourced, and the tester will tell the developers that the test failed, but will omit the one bit of information that allows them to diagnose the problem. Having the testers down the hall, so the failure can be reproduced in the presence of the developer, is invaluable.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
This is the fatal flaw in Agile; sprints don't allow for proper testing.
The best testing I've had were when the testers answered to different managers and had an arguably adversarial relationship with developers. The testers job is to prove the software doesn't work, not that it does. Another way to put it is that testers and developers are trying to prove that the others are incompetent.
|
|
|
|
|
Joe Woodbury wrote: This is the fatal flaw in Agile; sprints don't allow for proper testing. After having worked under an agile regime for ten years, and seen testing growing from a developer left hand activity to a well organized and maintained automated setup, I cannot agree. Test plans are set up for nightly builds, for different phases of the release (to customers) process, and for stress testing and other special test setups. Having a fully automated test set up is of course a great advantage - agile organization or not.
There is nothing about sprints that prevents nightly test builds. The test team sprint schedule is independent from that of the development teams, so they can freely e.g. run stress testing, and develop revisions of the test setups, as if it were "ordinary" software.
Even though we have seen lots of test frameworks claiming to handle GUI testing, they rarely work very well, in particular if the user dialog changes every day. But if your application is properly designed, you may peel off the thin GUI layer to let the test framework interface at the topmost functional level, and the entire application logic may be tested. The problem is that lots of web applications are not properly designed, with lots of application logic inseparably mixed with low level presentation elements. That's a problem created by JS and web application development frameworks, not by agile environments and sprints.
You may be thinking of other aspects of testing that I am overlooking. But we have several major projects all running sprints, and all running regular (automated) testing. So at least some (I'd say 'quite a lot of') proper testing can very well be done within an agile sprint-based development environment.
|
|
|
|
|
You know that I'm not talking about automated testing. The context of the original post was about manual testing (by humans) and whether that should be done within a development team or separate from it. Agile sprints do NOT allow for independent testing; instead Agile has the conceit that automated testing is sufficient. It is not.
Over dependence on automated testing has led to a decrease in software quality. There is no substituting someone using the software like my father. Moreover, even in automated tests, you can test only that which you anticipated or for which the software was designed. (Such as suddenly moving the software to an international market.
|
|
|
|