Be able to understand and evaluate Big-O notation and use hash maps and sets. Which if you don't already know, you should!
I have built and seen succeed and crash-n-burn spectacularly a variety of automated test frameworks for large enterprises. Let's start with the successes:
- High availability / Robust
- Staging environment for automated test developers
- Performance metrics
- Easy to understand test results
The failures were due to:
- Brittle and poorly designed tests which don't run the same in the CI system versus the tester's machine
- Testers committing bugs into the test environment
- No performance metrics
- Hard-to-understand failure results require duplication and deep analysis
As you can tell, the failures are the opposite of the successes. Allow me to further explain.
The most important item is that the tests always work and always be running. This means test machines and back-up test machines. Running the same test on three different machines is even better because you can throw away or temporarily ignore outliers. Outliers need to be addressed eventually, but for day-to-day developers and managers just want to know if the code they committed causes failures. Having the test be in any way unreliable causes faith in the tests to disappear. The tests must run, and they must run well. Test environments go down or require maintenance and you want to be able to continue to run tests during these downtimes. Treat the tests like a production system.
Next, a big improvement I've seen is to have automated test developers contribute new work to a separate-but-equal staging environment. Automated test teams run on an Agile/Scrum iteration and only "release" their new tests at specific times. Another thing which reduces faith in test results if the tests are breaking due to the fault of automated test developers-- which happens all too often.
Automated tests are the ideal platform for generating performance metrics.
Lastly, a big pet peeve of mine is for understandable test failures. Test failures should obviously describe the set-up, expected and actual result. If test failures are obtuse and require a lot of time to analyze and triage-- that is wasted time that could have been spent fixing the root cause.
Good luck! If past experience is any indicator, you will be spending far more time and money than you ever imagined to create a robust system that developers and managers will have faith in.
Though at the time, I was a long time user of Commodore Amiga. Most PCs at the time were extraordinarily difficult to configure and keep running. I remember the multi-tasking in Windows 95 being really bad-- explorer.exe getting blocked. Other things that stick out to me were over use of modal dialogs and that lower-right notification tray filling up with animated distracting icons.
Don't get me started on clippy, or DOS, or file system naming conventions. Sure, compared to Windows 3.1 it was bliss-- but other computing platforms were years ahead.
And? If there's no middle man then ultimately someone (in this case it sounds like the buyer) has total control over the transaction. It doesn't matter what UPS says, if they don't want to release the funds they don't have to.
In a dark market like this the ONLY protection you have against fraud is the other party's reputation.
Did you even read the article? It describes how a third party (arbiter) is agreed to by each party. It takes 2 out of 3 signatures to finalize the transaction (minus arbiter fee).
I am mostly interested on when the phone will be released for USA markets and what bands it will support.
Activities are just workspaces. They might offer a little more customization than a workspace-- but that's all they are.
I used XFCE for many years on this same machine-- without compliant. What I liked about KDE is that it ran as well as XFCE and came with everything I needed for Qt development. Also I don't need to double-load application frameworks. Iv'e been able to use KDE or pure Qt apps for everything I need.
As for drop-shadows, bouncy cursors and business-- that's both accepted and came be done tastefully. (**Cough** Unity **Cough) Like any environment, customization is both available and desirable. IMHO it was easier for me to get KDE where I wanted then Unity or XFCE
This is a big win for the Qt ecosystem. Between KDE libraries reworked into portable Qt modules and official iOS and Android support even with support from Digia-- Qt is gaining momentum. They even managed to survive being gobbled by Nokia, then being sold to Digia-- it has been a bumpy ride.
I recently tried out the latest Kubuntu and have been loving it installed on an old Dell D410 (12inch, 1.8Ghz SC Pentium, 1.5G RAM) laptop and it runs well and does everything I need (which in this case is Qt related application development
> As I'm getting back into C++ after almost 20 years and trying to start with Qt, I'd love to see some practical examples.
Sure. new signal slot syntax covers how to create anonymous lambda handlers for signals. No longer is it required to create methods on our public interface for a slot. This is pretty much The Big News (tm) when it comes to closures in Qt. But in general, I have late taking towards creating methods and interfaces which expect and rely heavily on callbacks-- and the new C++11 lambda expressions are now a very terse way to accomplish callback mechanisms in C++. Conceptually, it has always been possible, and the C++ 11 lambda extensions are effectively code inliners to accomplish the same task as creating a class to wrap state with a callback method-- which needed to be done by hand previously or attached to an existing class (further muddling its interface).
There are many things Qt does very well, some not so well and some pieces completely missing. Opening up KDE as plug-in frameworks will fill in the holes in Qt for bringing very strong applications to a whole new generation of embedded and X-platform tools. Also, C11 C++ extensions and more specifically closures have really helped me fall back in love with C++ primarily through Qt.
After our family got together and played Myst over winter holidays, there was much discussion that we could do better. My dad, uncle, aunt, cousin and others worked for 4 years to make Morpheus which was released in 1998 by Piranha interactive. Piranha very shortly went broke and paid little of what we owed. We all went back to our lives, but there are still background attempts at rebooting the game.
What would you recommend to organizations to curtail the sort of social engineering break-ins for gaining unauthorized entry?
//GO.SYSIN DD *, DOODAH, DOODAH