|
> Just for sh*ts and giggles I did my last project, a web application with about 10
> pages and 6 database tables all using my ADO.Net DataAccessLibrary that I wrote 8
> years ago and standard ASP.Net.
Out of curiosity what kind of Unit Testing did you provide with that?
-Rd
Hit any user to continue.
|
|
|
|
|
None. I have never done any unit testing. I test my methods as I code and have actual users do user acceptance testing. We also have a project manager write up a test plan with users. I've never done any unit testing, nor do I plan on it in the near future.
I didn't get any requirements for the signature
|
|
|
|
|
ToddHileHoffer wrote: None. I have never done any unit testing. I test my methods as I code and have actual users do user acceptance testing. We also have a project manager write up a test plan with users. I've never done any unit testing, nor do I plan on it in the near future.
That's what I figured, and that's fine.
The reason I asked is that I feel you'd probably find those the usefulness of various different frameworks is driven by the variety of things you want to do. If you are churning out roughly the same type of app in roughly the same way, if you aren't looking at Automated Unit Tests or Automated Acceptance Tests then yes, you'll work quite happily with the same tools you've used for years.
If you try to move into those other areas you'll find you hit limitations in your toolset, and you'll find that some of those other frameworks have something to offer.
So, by all means keep doing what works for you, but don't dismiss the tools and frameworks that you don't use. It may be that they solve a problem that you are not faced with.
Best of luck
-Richard
Hit any user to continue.
|
|
|
|
|
What is really frustrating is that by the time I get around to finally learning and implementing a particular framework or technology Microsoft is already on to the next one. When I find bugs or issues in the existing framework the attitude is one of "why are you still using that?" instead of "we'll fix it." They are moving too fast and leaving many developers who are doing more complex projects with longer lifecycles behind.
Sean
|
|
|
|
|
I'm running VS 2008, BTW, as it's the last full version I have (of course, I have the Express versions for 2010.)
It seems that the only projects that I am allowed are:
- Console App
- Library
- Tutorial
I am also allowed to add in the item:
- Source
- Script
- Signature
Is this all I'm supposed to have?
I'm trying to figure out what's the point in having this new language if you can't really do anything with it! 
|
|
|
|
|
First, stop whining. Second, go here[^].
F# was never made an integral part of VS2008 because, back then, it was still a toy to play with, a CTP. You weren't meant to write entire apps in the thing!
Hell, you don't get a template for an F# Windows Forms app in VS2010 Ultimate! It's still pretty much a toy. The most I've used it was to work on Project Euler problems, none of which required the use of forms.
Though, you can still probably just manually add the refences and write all the code to add the controls yourself. Designer support isn't available, unless, of course, you either find or build a project template (at the very least!)
|
|
|
|
|
OK, so right now it is a toy. But then why is Micro$oft pushing it so much? Are they planning to release F# as a true development language in the next Visual Studio release? Perhaps they will replace Visual Basic with Visual F#? If that's the case, maybe I'll play with it in anticipation of that.
|
|
|
|
|
swampwiz wrote: Perhaps they will replace Visual Basic with Visual F#?
I can't see them ditching VB anytime soon. There sell far too many visual studio packages to VB users so way too profiatable to dump. Also, most of their hard work is already done - once they have developed new goodies for new versions, it doesn't generally cost a great deal to add in VB support.
|
|
|
|
|
They're not ditching VB.NET and replacing it with anything.
F#'s strength is in dealing with sets of data. You can use it to build libraries of processing units to handle your apps data more quickly and efficiently than you can in non-functional languages.
|
|
|
|
|
OK, so F# is really only designed to work as a data Library component. Perhaps it is well suited to building some type of specialized data structure for situations in which using SQL Server would not be appropriate? That would make sense.
|
|
|
|
|
If you must whine about some product's failings then please do so in the appropriate place[^].
The best things in life are not things.
|
|
|
|
|
While C# and VB.Net are roughly equivalent and great for building a variety of different types of apps, libraries, services etc, F# is a specific type of language for functional programming (FP).
You're coming at it from the wrong angle if you think of F# as being equivalent to VB.Net. It's not intended to do the same job.
I think most people would envisage F# being used to implemented specific bits of logic in a functional manner, using VB.Net or C# as a front end.
Pretty much every problem can be solved without resorting to Functional programming, but if you are working with certain types of problems the use of FP can provide startling improvments (less code...cleaner simpler more logical solutions)
Even if you see an opportunity to use FP, you will probably find you can do what you need using FP features of C# rather than resort to F#.
Forget about F# for now, look into FP in general. The whole paradigm might not even be worth your while. I find it facinating but I've yet to find a use for it in my projects. I'm sure I will though.
Like a lot of things, even if you never use FP, it will change the way you think about your procedural code, so it's worth a look.
F# will never replace VB.Net.
A more likely scenario is that C# will expand to provide all the Functional Programming Goodness and there won't be a need for a separate language. FP could represent a splitting point between C# and VB.Net because I really don't see much point trying to shoehorn FP into VB.Net. Most attempts to do so lead to UGLY UGLY syntax.
I don't want to start a war of words here, but as a very long term BASIC>VB>VB.NET developer, I've switched to C# and I won't ever go back. I should have switched a long time ago.
-Rd
Hit any user to continue.
|
|
|
|
|
Hi
I have a folder called OTRS Ticketing system which is developed using Perl. I need to open the perl files in design mode so that i can make any changes in design layout . Is there any Perl IDE for opening & changing design layout.
I downloaded Editplus, Komodo but all are one we can view code and make changes in code. But not able to see as design view.
How to do this. Any suggestion for Perl development tool which we can use for opening perl files in design mode.
Anybody knows, please reply.
Thanks in advance.
|
|
|
|
|
You might want to ask in a Perl forum/site.
sr159 wrote: I need to open the perl files in design mode so that i can make any changes in
design layout
And why exactly do you think you "need" to do that?
I suspect Perl isn't doesn't fit that as nicely as something like C# does.
I would also suspect that perl created without that idiom isn't going to be well suited to such a use even if something supports it.
|
|
|
|
|
I am building a diagramming tool that will import an SVG as background and then create a network like diagram on top of it.
The objects that i will be using to draw diagram will also be SVG files.
So I would like to know whether the WPF is the way to go or something else?
Bharat
|
|
|
|
|
If you are comparing WPF(Xaml) to Windows Forms (GDI+) I'd go the WPF route. Don't quote me but Xaml is a subset of SVG, GDI+ is not. Another option would be Silverlight which is also Xaml based.
"You get that on the big jobs."
|
|
|
|
|
Thank you so much.
Bharat
|
|
|
|
|
Hello,
I am working on a GUI for XNA. I deliberately work on an older computer with a GeForce 7900 graphics card, so that I run into performance issues quicker than on a more up to date system. There is a small testing application that displays a GUI window with controls over an animated 3D scene. Here is a screenshot (sorry for the models, I'm not much of an artist):
http://img829.imageshack.us/i/screenshotja.jpg/[^]
Most work is done in two threads. One does the rendering, the other one is the UI thread. I have noticed, that both threads are always running on the same CPU core. For testing this is great. It forces me to do some profiling and refactoring when the CPU hits the ceiling. Under normal circumstances I would prefer to have the rendering thread on one core and the UI thread on the other. This way both thread would have lots of reserves left and should never get into any performance problems.
The problem is that I don't appear to have much influence on where the system schedules the threads. Am I overlooking something? Is there a way to make more efficient use of the CPU cores?
Edit: Sorry, I forgot: Pls gimme codez. Its urgentz. 
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011
---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011
modified on Tuesday, April 19, 2011 2:17 AM
|
|
|
|
|
The behavior of CPU load on multicore machines is very strange. When I run a Virtual machine with one virtual processor on a dual core host, and the virtual machines requires 100% of "its" core, Windows task manager does not report one core at 100% with the other at a low amount, but both cores with varying loads amounting in sum to just more than one fully used core.
Consequently, I would not worry about how to get the work load balanced between the cores, the operating system (same effect on Linux!) - or even the processor itself - is doing something already.
|
|
|
|
|
Well, both threads together run at 70% average of the one CPU they both run on. Sometimes the UI thread needed a little more and that CPU goes up to 100%. This also affects the rendering thread and the result is choppy rendering. I was able to optimize those peaks away and everything is fine now, but the point is that I want to prevent this as good as I can. Up to now I saw nothing that would make me hope that the system does anything to prevent that.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011
---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011
|
|
|
|
|
This[^] says don't do it, then gives you links to how to do it....but not for .NET
CDP1802 wrote: Edit: Sorry, I forgot: Pls gimme codez. Its urgentz.
But here[^] has some C# code using an interop.
Not going to yell about not Googling "setting thread affinity", since I never would have looked it up, otherwise. Gonna play around with it, now.
|
|
|
|
|
Thanks. You can't guess how much I googled and searched for threads and processes. But it's really easy as soon as you know the right name for what you are looking for.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011
---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011
|
|
|
|
|
Like asking someone how to spell a word and they say Look it up. 
|
|
|
|
|
I would like to start playing around with the supposed great new language. I have Visual Studio 2008 and all the Visual Studio 2010 Express IDEs. I downloaded the F# development packages (InstallFSharp & InstallFSharpPowerPack.) It seems that the only thing I can do to use F# is to open some crappy console window. Is there any way for me to be able to set up regular WinForm & WebApp components with F# through one of my existing IDE's? What would be the point in me trying to help out Micro$oft's new language if the damn thing will only allow me a crappy console IDE? Why would I want to waste my time on this? 
|
|
|
|
|
If you compare a C# winforms project with a console project you will see the main difference is the Program.cs file calls Application.Run with a new instance of the start up form. Also the project output type (in project properties) is set to Windows Application instead of Console Application.
You can do this in F# too. First change the project output type to Windows Application.
Then, you can create a form in code and send it to Application.Run:
open System.Windows.Forms
let formMain = new Form()
Application.Run(formMain)
I'm not sure if it's possible to use the designer to create/modify forms though.
[Edit] You will also need to add a reference to System.Windows.Forms of course! [/Edit]
[Edit2] Just found this article[^] [/Edit2]
Dave
Binging is like googling, it just feels dirtier.
Please take your VB.NET out of our nice case sensitive forum.
Astonish us. Be exceptional. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
modified on Thursday, April 14, 2011 3:53 PM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
