Quantcast

Maximum PC

It is currently Thu Oct 02, 2014 5:46 am

All times are UTC - 8 hours




Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Mon Jun 20, 2011 8:32 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
Don't have time to reply to everything right now, but this isn't true at all... In either case you at least need a stub of the object to be able to use intellisense against it and get the project (or in my case projects) to compile. You don't have to have the function implemented but it must be stubbed.

Actually, the idea behind writing the tests first doesn't require you to compile them. You're checking that the design/interfaces you've created work in the way you intended before you spend time implementing the code. If the unit test code is difficult to write or use, then you know that you need to go back and redesign before doing the implementation.

CrashTECH wrote:
Why on earth would you want your test built with the library when you will eventually want that code removed. You don't want to release your tests with your code. Put them in separate projects and then they never will be released unless you physically include a reference or copy a DLL file.

Actually, DJ brought up a valid point. In the past few years, it has become more and more popular for teams to distribute their code with the tests to ensure the software will work on the customer's computer (usually for in-house software).


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Tue Jun 21, 2011 3:02 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Gadget wrote:
Actually, the idea behind writing the tests first doesn't require you to compile them. You're checking that the design/interfaces you've created work in the way you intended before you spend time implementing the code. If the unit test code is difficult to write or use, then you know that you need to go back and redesign before doing the implementation.
My only experience with unit tests was in a compiled sense. Everything in .NET is compiled, so ?? interfaces have no implementation. How can you test that it works without implementing something that uses the interface? I have never had the chance to work in a company where anybody had "time" to do "proper" unit testing or TDD. Even on the new code that I wrote there wasn't any time built in for doing anything but normal testing that you should be doing anyway.

Quote:
Actually, DJ brought up a valid point. In the past few years, it has become more and more popular for teams to distribute their code with the tests to ensure the software will work on the customer's computer (usually for in-house software).
I am sorry, but that is stupid. If developed correctly there shouldn't be any reason why your tests would need to leave your development and QA environment.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Tue Jun 21, 2011 8:27 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
Quote:
My only experience with unit tests was in a compiled sense. Everything in .NET is compiled, so ?? interfaces have no implementation. How can you test that it works without implementing something that uses the interface? I have never had the chance to work in a company where anybody had "time" to do "proper" unit testing or TDD. Even on the new code that I wrote there wasn't any time built in for doing anything but normal testing that you should be doing anyway.


Unit testing ensures that the code behind is proper. I unit-test all of my libraries that I wrote - and I mean, *ALL*. No one wrote an Active Directory Library for us, so I wrote one - used Unit Tests to prove that my AD calls are right, I used to check the objects being returned and I used to ensure that I'm parsing my stuff correctly. Once each unit test passes, I implemented the code - refactored as needed.

Unit testing is also good for fleshing out more behavior: implementing an interface, running tests is just one way of testing an interface. However, if you find yourself testing functionality but need to split an interface, then the split happens locally in the test. You can retest the new split interface by refactoring and re-running your unit tests...this way you always ensure that the code you implement is 100% tested. The amount of time I spend testing is negligible considering that if my manager asks me about my code, I can at least guarantee a level of code-coverage (60% is ideal for me, since I'm a lone developer).

Quote:
I am sorry, but that is stupid. If developed correctly there shouldn't be any reason why your tests would need to leave your development and QA environment.


Because testing code is different from testing a final product - even in test environments. Testing in a development or QA environment tells me something about the run-time, but as errors crop up, it gets more and more difficult to track where the error occurred. I live in a world of tiny budgets (or none at all), so it's not like I can go and purchase profiler tools from Red Gate. So the next best thing? Unit testing. Also, if you open source code, including your test with your code enables other developers to understand the functionality of your program through tests. This is why I'm a big fan of BDD.

Anyhow, for me, testing is important and Rails facilitates that desire. The automated tests is a great way to streamline my productivity, partly because I don't need to switch projects!


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Tue Jun 21, 2011 9:18 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Gadget wrote:
While we're on the topic, have either of you worked with CyberCoders? Apparently, they're a pretty large consulting firm and they have some positions that look pretty interesting. A quant position and android dev position paying $70/hr caught my eye.
No experience with them. I haven't even heard of them.

I had a similar experience with Dice. It is nice to know that there are lots of jobs for those with talent.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Tue Jun 21, 2011 9:22 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
DJSPIN80 wrote:
Because testing code is different from testing a final product - even in test environments. Testing in a development or QA environment tells me something about the run-time, but as errors crop up, it gets more and more difficult to track where the error occurred. I live in a world of tiny budgets (or none at all), so it's not like I can go and purchase profiler tools from Red Gate. So the next best thing? Unit testing. Also, if you open source code, including your test with your code enables other developers to understand the functionality of your program through tests. This is why I'm a big fan of BDD.

Anyhow, for me, testing is important and Rails facilitates that desire. The automated tests is a great way to streamline my productivity, partly because I don't need to switch projects!


I still disagree with releasing test code with your application. I have automated error logging and such that can send specific details back to the developer. I don't see how deploying your application with the test code does anything for issues that crop up in the wild. You don't need profiling tools to find errors.

In F/OSS that is different. Leave it in the repo.

Testing is most definitely important! I wouldn't try to dispute that at all.

You DO NOT have to "switch" projects! I really wish I had time to create a sample VS solution so we could look at a concrete example. A visual studio solution has many projects. You just open the code file! In VS 2010 you can even have them side by side on a dual screen system and read both files with ease. I still am not seeing how keeping the code/tests logically separated is a downside.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Tue Jun 21, 2011 9:36 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
Quote:
Haha... how do you manage with a vibrant social life.... =)


Quote:
While we're on the topic, have either of you worked with CyberCoders? Apparently, they're a pretty large consulting firm and they have some positions that look pretty interesting. A quant position and android dev position paying $70/hr caught my eye.


I've heard of them, they're like every other large recruiting firm - hit and miss. Sometimes, they do a good job and get my feet in the right doors, but other times, forget it. In the years I've worked, 100% of my jobs have been obtained through my own searching. Never has a recruiter partnered me with a good company that I actually wanted to work with.

That being said, they do have a good reputation. I believe we used them when I worked at the bank, so they at least have a large pool of talent.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Tue Jun 21, 2011 5:04 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
My only experience with unit tests was in a compiled sense. Everything in .NET is compiled, so ?? interfaces have no implementation. How can you test that it works without implementing something that uses the interface?

No no no... you're thinking in terms of compiled vs interpreted languages. The reason that XP advocates suggest writing unit tests first is because you want to "exercise the design" to make sure that the interface you've implemented is solid in the "I really like using this API sense". Writing the unit tests first forces you to use your own design and hopefully prevents you from becoming the guy that wrote something fugly like COM.

CrashTECH wrote:
I have never had the chance to work in a company where anybody had "time" to do "proper" unit testing or TDD. Even on the new code that I wrote there wasn't any time built in for doing anything but normal testing that you should be doing anyway.

Why don't you consider unit testing to be "normal testing"? The TDD guys would argue that TDD actually saves time in the long-run. You know the whole "bugs caught early cost less" thing from SE courses.

CrashTECH wrote:
Quote:
Actually, DJ brought up a valid point. In the past few years, it has become more and more popular for teams to distribute their code with the tests to ensure the software will work on the customer's computer (usually for in-house software).
I am sorry, but that is stupid. If developed correctly there shouldn't be any reason why your tests would need to leave your development and QA environment.

Actually, if the code you write depends on many external libraries, then distributing the unit test code will often save you a lot of trouble. At Boeing, despite the companies best attempts at ensuring that everyone had exactly the same software installed, there were dozens of people with JVMs that were over three years old. I'm not really for or against the practice. In the worst case, it blows up your code by maybe 200K. Not really a big deal considering the abysmal quality of most developers algorithms and data structures (knowledge & implementation).


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Tue Jun 21, 2011 9:48 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
DJSPIN80 wrote:
Quote:
I am sorry, but that is stupid. If developed correctly there shouldn't be any reason why your tests would need to leave your development and QA environment.

Because testing code is different from testing a final product - even in test environments. Testing in a development or QA environment tells me something about the run-time, but as errors crop up, it gets more and more difficult to track where the error occurred. I live in a world of tiny budgets (or none at all), so it's not like I can go and purchase profiler tools from Red Gate. So the next best thing? Unit testing.

Actually, I find unit testing to be far and away the most worthwhile kind of testing... especially when working with lousy programmers (they're the ones that argue the loudest about how THEIR code couldn't possibly be at fault), when inheriting/maintaining code that you didn't write (esp libraries), or when integrating code bases. The original rules engine that I mentioned in the other thread had tons of errors. I seem to recall writing unit tests for something like four hours straight (after lunch) and then filing something like 60 change requests the next day because the people who originally wrote it never wrote any unit testing. They weren't really proactive about testing... more of the lets do an acceptance test and let the system engineers file the change requests when they find errors. The unit tests were the straw that broke the camel's back and allowed my manager to get funding for us to rewrite the damn app. I probably could have found 500 errors if they'd given me enough time.

The same team had a set of something like 400 or 500 SQL queries/checks that was supposed to be an indicator of the maturity of the data in the database. The system engineers really believed these things were gold. Most of these queries had been around for better than 10 years and were 'bullet proof'. After looking at a few of them and realizing they smelled to high hell, I used one of the database testing frameworks found out that SIX of the first TEN queries that I tested were wrong!

1. Never trust any code that isn't unit tested.
2. Always write unit tests for your code.

Regarding regressions errors: automated unit testing is far faster, cheaper and more complete than any kind other kind of regression testing that I've seen done. I'm also a big believer in the idea that if you can't unit test piece of code then your design is bad (w/ some exceptions for web apps and database code). Time to refactor.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Tue Jun 21, 2011 10:11 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
DJSPIN80 wrote:
I don't use intellisense, so. :P
Why? Do you like punching yourself in the dick when you program?
OK, so I was having trouble imagining what is big deal about Intellisense (because I didn't remember it being different than any other autocompletion system) and took a glance on wikipedia...

Quote:
Similar to other autocompletion systems, IntelliSense is a convenient way to access descriptions of functions, particularly their parameter lists. It speeds up software development by reducing the amount of name memorization needed and keyboard input required. It also allows for less reference to external documentation as interactive documentation on many symbols (i.e. variables and functions) in the active scope appears dynamically in the form of tooltips while programming.[1]

So what is the big deal? EVERY IDE does this.

DJSPIN80 wrote:
!!!!!!!!!!! Dude, I can't agree with this. You should NEVER EVER EVER EVER be testing in production! Period! No ifs, ands, or buts. What are you doing man! It doesn't matter what language, that is just bad! You need a proper pre-live environment. If you don't have one, priority number one is to get one! Don't for the love of whatever deity you believe in test in production!

What are you calling a pre-live environment? Is that some new terminology for a web app/database testing framework/environment or just a test server with a test database?

And a lot of people run their unit tests whenever they build Crashtech. That is actually one of the XP commandments.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Wed Jun 22, 2011 4:05 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Gadget wrote:
So what is the big deal? EVERY IDE does this.
Right. I wasn't under any impression that they didn't. I just don't see why you wouldn't use it and any other facilities that aid in increasing the speed at which you write code.

Gadget wrote:
What are you calling a pre-live environment? Is that some new terminology for a web app/database testing framework/environment or just a test server with a test database?

And a lot of people run their unit tests whenever they build Crashtech. That is actually one of the XP commandments.
The way I see development working (unit tests is one thing btw, It isn't the be-all-end-all!) is the developer has his local box and a development environment. A place that he can trash however he (or she, whatever) wants to. Then there should be a test environment where the system can be reviewed internally. Pre-live (staging, QA, whatever you want to call it) should be an exact copy of production. Both hardware and data. The thought with this is that you could do load based testing and put some real clients in the system.

In an ideal world, once you have the code up and running and verified, I would swap production and pre-live. The pre-live server is now live production and vice versa. It removes chances for human error with deploying code and configurations etc.

I am not against unit tests, seriously I am not. After having a few years of experience, a lot of established companies aren't likely to adopt all of the new programming "fads" (you know there will be new stuff in a few years that will replace the current paradigms). There just isn't time or money to make that change and still keep up the run the business costs. The only way would be for developers to spend countless hours of unpaid time (yeah right, are you kidding me?) to make the changes quietly behind the scenes. I have been VERY hesitant to do anything like that. Because as soon as I do, it will become expected. I think 40 hr work weeks are ridiculous as is for a variety of reasons, and I won't set myself up for an expected 50 hour week.

I understand that DJ is disenfranchised with the business world and for the most part Gadget is an academic. But the two worlds are very different. Things are slow to change for the vast majority of companies. They have massive code bases that it just isn't feasible to re-write or to start building unit tests. You just have to make due with what is there, and often a lot of it is very, very bad.

TDD is great for NEW development. However I'd argue that a very high percentage of development work is not brand new.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Wed Jun 22, 2011 5:38 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
Quote:
I understand that DJ is disenfranchised with the business world and for the most part Gadget is an academic. But the two worlds are very different. Things are slow to change for the vast majority of companies. They have massive code bases that it just isn't feasible to re-write or to start building unit tests. You just have to make due with what is there, and often a lot of it is very, very bad.


Hehehe, disenfranchised? Maybe...but with MSFT and their direction. The business world can be invigorating, if you work or follow the best people. I often follow the guys at 37 Signals, they are a breath of fresh air in the business world. Lately, I've been reading Rework (from the same guys at 37 signals) and want to pick up a few books from Zappos' Tony Hsieh.

I don't like to think of myself as a disenfranchised programmer. Bored? Sure. :)

Quote:
TDD is great for NEW development. However I'd argue that a very high percentage of development work is not brand new.


I think Gadget hit the nail on this one. Even with existing development, TDD is great. TDD allows for faster ramp-ups because the entire user-story of the application is contained in tests, so it's literally a requirement spec told in the story of test. Instead of spending hours looking at the application, look at your TDD test cases and you get a high-level view of the app.

I agree with Gadget that it can be used to test existing components for validity in older software, it can also be used to test old-code tie-ins with new-code. TDD has great value, it's not just a "new development" deal.

One more thing; if you use BDD tools like RSpec or Cucumber, the test cases are actually readable.

Code:
describe "Password encryption" do
   it "should encrypt password when user is created" do
            #... code here
   end
end


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Fri Jun 24, 2011 4:36 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
I know we kind of got off on a tangent, but to get us back to the original topic... I think DJ's post might have been a bit too early (I know I was concerned with the Win8 announcement about HTML5 and JS, like many developers). It is still way too early to tell but I wouldn't count Microsoft out yet.

http://arstechnica.com/microsoft/news/2 ... reborn.ars

I think that WinRT is exactly the thing you were complaining that Windows didn't have. :)

The biggest paragraph from the article is this one:

Quote:
A single, modern, unified Windows API at last

The point of all this? It gives parity to native C++ and managed .NET code. Instead of being separate, each with its own different capabilities and strengths, they will be peers. If Microsoft adds new APIs to core Windows, the WinRT system will ensure that they're seamlessly available to managed code, meaning that .NET developers will no longer be at a disadvantage relative to native ones. Conversely, existing native applications can be updated to use the new UI without having to be substantially rewritten to use .NET. This same flexibility applies to Microsoft: putting native and .NET code on an equal footing opens the door to actually seeing .NET applications shipping with the operating system.


I know I am the resident MS and Windows "fanboy" here, and I have no issues with that! I am totally a huge supporter of MS and pretty much always have been. That isn't to say that I am against other things, if anything I am for them. Why? Because it has finally forced MS to stay on their toes and work doubly hard to make things better. At the same time, F/OSS needs to keep moving (as they do have some ground to still catch up on even) to push back. This is exactly the kind of "competition" that fosters rapid and advances and new development.

Color me excited again!


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Sat Jun 25, 2011 9:42 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
It seems really cool and all, but it's ten years too late for me.

This philosophy should have been adopted back in Windows Vista - back when .NET was at the height of her fame. From what it seems, they're using the word "peer" to really mean "parallel". The native API's and .NET will appear seamless and will work together as "peers" but what they seem to mean is that they will work in parallel to each other. That is, .NET is still being given that shaft (IMO).

My biggest complaint is that MSFT should have standardized years ago and used a singular framework rather than this crappy duopoly. .NET was an excellent platform that they never really, fully capitalized. Now that they're finally standardizing to WinRT - I think it's great, but a little too late for me.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Mon Jun 27, 2011 9:30 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
I still disagree with releasing test code with your application.

Yes, but you haven't given us a good reason WHY you shouldn't do this. As far as I can tell there is no harm in it. Sure, you mentioned alternative that everyone does like...

CrashTECH wrote:
I have automated error logging and such that can send specific details back to the developer.

You're basically saying "Yeah, if there is an error, I'd like to know about it." When an exception is thrown, you'll get back a call stack and (hopefully) details about what arguments were passed to a method, right? This is good information to have when diagnosing a problem that you did NOT anticipate, but critically, it is still a reactive treatment for dealing with errors. With the unit tests, you'd be saying "I want to make sure these things won't be an issue."

CrashTECH wrote:
I don't see how deploying your application with the test code does anything for issues that crop up in the wild.

The people running your code may be using a different virtual machine or architecture, might have a much slower or faster network or database, might have a bad set of libraries installed (ie DLL hell). Hell, one time we had an internal team that was using the wrong version of the database schema (granted, it wasn't our fault they were idiots, but we still had to hunt down the problem). Natually, you won't be able to write unit tests to cover all contingencies, but whenever something does happen, you can then write a unit test and know that it will be easy to diagnose if it ever appears again on another machine/environment.

CrashTECH wrote:
You DO NOT have to "switch" projects! I really wish I had time to create a sample VS solution so we could look at a concrete example. A visual studio solution has many projects. You just open the code file! In VS 2010 you can even have them side by side on a dual screen system and read both files with ease. I still am not seeing how keeping the code/tests logically separated is a downside.

Let's pretend we've just changed a bit of existing code together in VS that already have unit tests. Can I now press the F10 key (or some other function/shortcut key) to run the existing unit tests?


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Mon Jun 27, 2011 10:07 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
There just isn't time or money to make that change and still keep up the run the business costs. The only way would be for developers to spend countless hours of unpaid time (yeah right, are you kidding me?) to make the changes quietly behind the scenes. I have been VERY hesitant to do anything like that.

Quoting Joe Rogan in the context of people being paid 20 cents an hour to make Nike shoes... "Uh, THEY should probably quit their jobs, but I don't know how to make a pair of shoes so..." =)

Usually it is an evolutionary process, if someone tells me to find a problem, I'm going to hunt down the problem and solve it and write a unit test(s) to ensure that it doesn't reappear (and assure myself that I actually fixed it). On average, I'd estimate that writing unit tests takes up less than 10% of the total time for a change request. Before long, you have a nice set of tests and fewer problems.

CrashTECH wrote:
Things are slow to change for the vast majority of companies. They have massive code bases that it just isn't feasible to re-write or to start building unit tests. You just have to make due with what is there, and often a lot of it is very, very bad.

True. Many (average) companies do have large code bases; Most of the code sucks pretty bad too. However, I don't think the problem is related to the cost of writing unit tests. In fact, I'd speculate that writing unit-tests saves companies a fortune in the long-run. It only takes a minute (to write) but can save an hour. Aside from a couple of GUI oriented tools that weren't really do much aside from querying a database, I don't think that I've actually seen anything approaching a good code base that didn't have a moderate number of unit tests.

The real problem is with company culture... Most SE managers are friggin' clueless and have no idea how to run a software project. They've merely adopted the same work model as a McDonalds manager: everyone meets, you do this, you do that, I'm in charge, etc. Eventually these dinosaurs will become extinct, but until that time, we can always quit and work for better companies (like Google where unit testing is highly encouraged).

CrashTECH wrote:
TDD is great for NEW development. However I'd argue that a very high percentage of development work is not brand new.

Certainly. It wasn't until a few years ago that Java replaced COBOL as the language with the largest existing code base; However, I don't think you need to limit unit tests to new code. If I'm given a project to maintain, I'll spend quite a bit of time going over the existing code and any 'smelly' code will be unit tested (and smelly code always has errors... always). If the managers or team lead is proactive, I'll get permission to take care of it then and there. If not, just improvise... "hey, what happens on your machine when you...". I've never worked for a team that didn't take action when a bunch of bugs have started to show up in the CR system (especially w/ external customers).


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Mon Jun 27, 2011 10:35 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
I know we kind of got off on a tangent, but to get us back to the original topic... I think DJ's post might have been a bit too early (I know I was concerned with the Win8 announcement about HTML5 and JS, like many developers). It is still way too early to tell but I wouldn't count Microsoft out yet.

http://arstechnica.com/microsoft/news/2 ... reborn.ars

That was a good link Crashtech. From someone who doesn't really follow MS development, I found that to be very informative; However, I wouldn't get giddy just yet. The long-term goal may be to unify and simplify their development APIs, but as the article mentions, MS has always talked about doing it, and never actually done it. They have a habit of not delivering on this promise.

How does DirectX fit into their frameworks? Can you make use of the DirectX API from .NET now? Will you be able to use DirectX in with either code base in Win8?


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Thu Jun 30, 2011 1:14 pm 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
I am on vacation, and it is awesome... but since I have a few minutes...

Quote:
With the unit tests, you'd be saying "I want to make sure these things won't be an issue."
If you did your testing properly before hand, there is no reason to deploy the tests. No code is ever perfect and that includes tests. The point is, if you unit test before you release, there is no reason to send that code out with the application. I guess it can't hurt, but why? What you release should be lean and mean and clear of any extra stuff. It is too easy to accidentally include debugging specific stuff when you don't take it all out. Releasing it with the application only increases that risk.

Quote:
The people running your code may be using a different virtual machine or architecture, might have a much slower or faster network or database, might have a bad set of libraries installed (ie DLL hell). Hell, one time we had an internal team that was using the wrong version of the database schema (granted, it wasn't our fault they were idiots, but we still had to hunt down the problem). Natually, you won't be able to write unit tests to cover all contingencies, but whenever something does happen, you can then write a unit test and know that it will be easy to diagnose if it ever appears again on another machine/environment.
Speed of the network or database is not my problem. DLL hell hasn't been a real problem in such a long time, that point is moot. You can't unit test for stupidity. You should be controlling the release processes anyway. Especially internally. How do you unit test for the correct database version anyway?

Quote:
Let's pretend we've just changed a bit of existing code together in VS that already have unit tests. Can I now press the F10 key (or some other function/shortcut key) to run the existing unit tests?
Yes.

Quote:
Usually it is an evolutionary process, if someone tells me to find a problem, I'm going to hunt down the problem and solve it and write a unit test(s) to ensure that it doesn't reappear (and assure myself that I actually fixed it). On average, I'd estimate that writing unit tests takes up less than 10% of the total time for a change request. Before long, you have a nice set of tests and fewer problems.
Here is the main issue I have with unit testing... how do you unit test the unit tests? I know it is supposed to be a small enough unit to be easily verifiable...but it still seems a little like writing code to test code. You can still have issue? How common is it to have issue with unit tests?

Quote:
True. Many (average) companies do have large code bases; Most of the code sucks pretty bad too. However, I don't think the problem is related to the cost of writing unit tests. In fact, I'd speculate that writing unit-tests saves companies a fortune in the long-run. It only takes a minute (to write) but can save an hour. Aside from a couple of GUI oriented tools that weren't really do much aside from querying a database, I don't think that I've actually seen anything approaching a good code base that didn't have a moderate number of unit tests.
I would challenge that. I am sure there are lots of above average companies with large, difficult to maintain code bases. It is hard to justify going back and spending extra time to fix things and add proper unit tests because it doesn't provide any forward velocity.

Quote:
The real problem is with company culture... Most SE managers are friggin' clueless and have no idea how to run a software project. They've merely adopted the same work model as a McDonalds manager: everyone meets, you do this, you do that, I'm in charge, etc. Eventually these dinosaurs will become extinct, but until that time, we can always quit and work for better companies (like Google where unit testing is highly encouraged).
Agreed. Although I find it highly unlikely that things will change very quickly. Just based on what I have seen. It is a dream and a highly unlikely one at that.

Quote:
If I'm given a project to maintain, I'll spend quite a bit of time going over the existing code and any 'smelly' code will be unit tested (and smelly code always has errors... always). If the managers or team lead is proactive, I'll get permission to take care of it then and there. If not, just improvise... "hey, what happens on your machine when you...". I've never worked for a team that didn't take action when a bunch of bugs have started to show up in the CR system (especially w/ external customers).
Well good on you that you have been able to get the time. I have never been able to get the time to fix it properly and set it up to avoid issue in the future. The emphasis is always on getting things done even if they are less that correct.

Quote:
The long-term goal may be to unify and simplify their development APIs, but as the article mentions, MS has always talked about doing it, and never actually done it. They have a habit of not delivering on this promise.
Agreed, but I can see the point of not talking about it because of the whole Win FS issue... it is easier to not announce things until you are sure they are ready than talking about things and having to remove them.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Thu Jun 30, 2011 1:44 pm 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
I lol'd.



Still haven't seen the movie this clip came from... need to do that.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Fri Jul 01, 2011 6:48 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 985
Location: Earth
Quote:
Speed of the network or database is not my problem. DLL hell hasn't been a real problem in such a long time, that point is moot. You can't unit test for stupidity. You should be controlling the release processes anyway. Especially internally. How do you unit test for the correct database version anyway?


DLL Hell may not exist for you but it does exist elsewhere. What happens when you go work elsewhere and you run into that problem? Might as well unit test in advanced.

Just because you can't unit test for stupidity doesn't mean you can't use unit tests to validate non-stupidity.

In Rails, running rake db:migrate triggers a schema update. This update is then recorded in the database as schema_version. We could write corresponding unit tests that checks for the correct schema version, and if the environment fails to see that schema version, then you'll know that the environment is not setup correctly and you can address the problem in production - while deploying!

Quote:
Here is the main issue I have with unit testing... how do you unit test the unit tests? I know it is supposed to be a small enough unit to be easily verifiable...but it still seems a little like writing code to test code. You can still have issue? How common is it to have issue with unit tests?


You don't. If the unit test is wrong, then you either scrap the test and rewrite it or you refactor it. However, the whole point of the unit test is to ensure that the code is right to begin with. In most cases, either 1. the requirements were wrong (because they changed) or 2. the person testing/using didn't understand what the requirements were. Unit testing's precursor is an understanding of what the client wants, the unit tests are just contracts (so to speak) that everything was done right. This is verified by the client. This is why Unit Testing is so integrated with Agile.

Quote:
I would challenge that. I am sure there are lots of above average companies with large, difficult to maintain code bases. It is hard to justify going back and spending extra time to fix things and add proper unit tests because it doesn't provide any forward velocity.


Good software teams should revisit old code and refactor. Especially if the life of the product is a long one. Good code is irreplaceable and often worth the time you put into it. Unit testing adds validation that this 'smelly code' is indeed right. Now, if the 'smelly code' looks smelly but meets requirements, maybe it can be refactored to make it less smelly (or smell clean) - but the validation that it meets functionality is found in the test, readability...well, that's through refactoring.

Quote:
The emphasis is always on getting things done even if they are less that correct.


I operated like this until I realized that I could be doing more to produce better code. Honestly, I don't like this 'getting things done even if they are less than correct.' Do we want to conduct experiments where the data is 'less than correct'? I don't. I don't want my doctor to diagnose me with something if his philosophy of dianoses is 'less than correct' because he needs to churn out patients.

I don't disagree that things need to get done, my argument is how much should we get done in order that we can still do it correctly? I'm with DHH on this one: small tasks, iterative development (i.e., Agile) and small batches for release cycles is the way to go. It ensures that when we release something, we release a correct product rather than trying to churn out 100 things but it works half (or three quarters of the time).


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Tue Jul 05, 2011 1:29 am 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
I am on vacation, and it is awesome... but since I have a few minutes...
Quote:
With the unit tests, you'd be saying "I want to make sure these things won't be an issue."
If you did your testing properly before hand, there is no reason to deploy the tests.

You can't guarantee that the client machine is going to behave like your test machine(s). It isn't a perfect solution, but it gives you the assurance that at least your unit tests work on the client machine. Have a good vacation!

CrashTECH wrote:
Speed of the network or database is not my problem. DLL hell hasn't been a real problem in such a long time, that point is moot. You can't unit test for stupidity. You should be controlling the release processes anyway. Especially internally. How do you unit test for the correct database version anyway?

You can't test for stupidity, but that doesn't mean stupidity won't waste your time! You see quite a few issues with DLL hell on govt job sites, but it doesn't have to be external libraries -- You want to ensure that the client is using the correct version of your library, right?

From what I've seen, most databases still include the equivalent of a 'database -v', so you could check the version that way or by using internal system tables. What I really meant is to test for the correct schema version. Many defense companies 'deliver databases' which can become a sort of data DLL hell. Generally, in this case, you would check that the schema information version stored in the database is correct. If you were paranoid, you might also include checks to make sure the schema was as you expect (check for tables, then fields, then data types using the system tables).

CrashTECH wrote:
Here is the main issue I have with unit testing... how do you unit test the unit tests? I know it is supposed to be a small enough unit to be easily verifiable...but it still seems a little like writing code to test code. You can still have issue? How common is it to have issue with unit tests?

Generally, if you're having trouble writing a unit test for a piece of code, there is a very high probability that the code in question is badly written. It needs to be refactored. I've never really had issues with unit tests, but I tend to write most of my code in a functional style, so I have small(ish) well-defined functions that are easily tested.

Regarding issues with unit test code...
true negative - The code is correct; The unit tests pass.
false negative - The unit tests pass, but the code isn't correct. You haven't done sufficient testing.
true positive - Here the unit tests fails on a piece of code with an error. Make sure that you don't have a false positive, then fix the code.
false positive - Usually this is easiest to correct (simply rewrite the unit test), but it might bring up some concern about your design (eg should I return null or an empty list).

IMHO, unit tests are invaluable. Sure, you can't test a UI very well with them, but you can find/fix many errors with them.

CrashTECH wrote:
I am sure there are lots of above average companies with large, difficult to maintain code bases. It is hard to justify going back and spending extra time to fix things and add proper unit tests because it doesn't provide any forward velocity.

What are the options? To not fix things? To not be proactive?

CrashTECH wrote:
Well good on you that you have been able to get the time. I have never been able to get the time to fix it properly and set it up to avoid issue in the future. The emphasis is always on getting things done even if they are less that correct.

Oh, don't get me wrong. I've also been bombarded with the "please figure out a quick fix" to someones craptastic software. I hate having to play the office politics games, but I'll play if that is what it takes...
"Uh, it'll take me longer to familiarize myself with the software than for the person who originally wrote it to fix it, so why don't you just have them fix it. From what I've seen, I can't believe this xxx works at all."
"If there was a quick fix, why hasn't someone already done this?"
"What do you mean that you don't actually want me to 'really fix' the software? You want me to leave it broken?"
etc. I actually hate playing games, but some places force it. Usually errors are clustered within software, so you can probably find enough additional errors to justify a proper fix.

Of course, you should probably be asking yourself the following question: why am I working for a company that won't allocate me enough time to properly fix their software? After all, you can't expect to get rich working for a companies that cannot afford to fix their software (w/ the exception of a few companies with monopoly power). Find a better job or ask for a transfer or something.


Top
  Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

© 2014 Future US, Inc. All rights reserved.