|
There are C# to JS compilers such as Script#, but frankly I rather suffer work with pure Java Script when I have to.
|
|
|
|
|
I love it. Web development is hard and TDD is dead on the same page.
95% of programmers can't bear the thought of having to work for a living. This stuff is hard. Grow up.
Test your code or go home.
|
|
|
|
|
IMHO it is getting better, just not fast enough. I still have clients stuck on EI9, which requires special treatment...err hacks, to work correctly. They are being held to IE 9 due to compatibility issues with other web applications.
It is appalling how many LOB web applications simply don't work with newer browsers...breakage usually caused by handling of client events or DOM references such as innerText not being recognized.
"Go forth into the source" - Neal Morse
|
|
|
|
|
These guy should really try Knockout[^]!
It almost feels like doing WPF interface with MVVM! 
I said just that to a younger developer that I introduced to Knockout here, now that you used MVVM with HTML + Knockout you are halfway through mastering WPF+XAML! 
|
|
|
|
|
I'm still only dabbling with knockout, but boy it's so nice!
Now, if I could just work out how to use knockout and typescript together I'd be a happy bunny
|
|
|
|
|
_Maxxx_ wrote: Now, if I could just work out how to use knockout and typescript together I'd be a happy bunny
Indeed we are!
Try sprinkle some WebAPI on top! ^^
|
|
|
|
|
Super Lloyd wrote: Try sprinkle some WebAPI on top!
Although I am using WebAPI on top of my Knockout, I'm still not bowled over by it - it's nice and easy to write a web service, but honestly that wasn't really hard before! I wonder if I am missing something?
re the knockout / typescript I'd appreciate any links to beginner articles on using them together - I haven't looked for a while but last time I did most of the info assumed you were a JS guru, and spent time explaining how things are different, rather than just 'how to use ...'
|
|
|
|
|
_Maxxx_ wrote: Although I am using WebAPI on top of my Knockout, I'm still not bowled over by it - it's nice and easy to write a web service, but honestly that wasn't really hard before! I wonder if I am missing something?
Well, what goes against it, I think, is that the default behaviour / config / usage is like ServiceStack which is rather convoluted and unintuitive...
However if you just add a one line route configuration in your AppStart, WebApiController behave just like MvcController, but for JSON data. Except they are fully typed instead of returning JSON result!
_Maxxx_ wrote: re the knockout / typescript I'd appreciate any links to beginner articles on using them together - I haven't looked for a while but last time I did most of the info assumed you were a JS guru, and spent time explaining how things are different, rather than just 'how to use ...'
Not entirely sure what you mean..  but I think I am getting quite good in Web now (as opposed to 1 and half year ago where I kind of was afraid of it! 
TypeScript is easy if you already know C# and JavaScript!
Start by renaming your .js file .ts: voila!
Have you read the tutorials on both?!
http://www.typescriptlang.org/Tutorial[^]
http://learn.knockoutjs.com/[^]
|
|
|
|
|
I guess what I'm after is a
"how to write a simple SPA using WebAPI, knockout and Typescript" tutorial
It is (relatively) easy to put it all together, but I'm interested in how people have used it as, ask you know, when you start doing something like this there will always be things you try and re-work a few times until you are happy with your basic model; I just want to avoid that part of the R&D so I can look at a working app, using that technology (and only that - without adding in more complexity like mapping modules etc)
Because I'm not a Web Dev guru, I need info that doesn't use phrases like "instead of doing it this way, like you would have with xyz technology, we can now do it this way" because I don't know xyz!
I have read the tutorials - it's just putting it all together I struggle with; even down to what is a good way of storing my JS, TS, knockout models etc. within a solution.
Super Lloyd wrote: TypeScript is easy if you already know C# and JavaScript!
Unfortunately my Js isn't exactly top notch!
|
|
|
|
|
Unfortunately my sample on my blog and codeproject doesn't compile with the latest version of TypeSript (it was written for 0.9.1)
It's fixed at work but not as easy to share...
Mm... this simple sample by Scott Hanselman use it all!
http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx[^]
analyzing it might bring you some insight! 
mm.. it doesn't use TypeScript... but really TypeScript should not be a problem, start by using it as you would JavaScript (after all legal JS is legal TS)
Then, overtime, take advantage of some feature, such as easy to write class! 
|
|
|
|
|
Danny Tuppeny wrote: (Web) Development sucks, and it's not getting any better
I see he is struggling to cope with the tech. He shouldn't have to struggle to fit in. He can change his career. May be he can try window apps, mobile ...
Wonde Tadesse
|
|
|
|
|
Last week, the Electronic Frontier Foundation released Privacy Badger, an extension for Chrome and Firefox. It’s an important piece of software in the struggle for internet privacy from a group with different motivations than other ad-blocker makers. Badger, badger, badger
Sorry for the earworm.
Ahh! A Snake! A Snake!
|
|
|
|
|
Kent Sharkey wrote: Badger, badger, badger
Sorry for the earworm.
Ahh! A Snake! A Snake!
Don't think much of the 21st century nursery rhymes.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Aw. This one[^] is an instant modern classic.
TTFN - Kent
|
|
|
|
|
Netcraft's monthly survey of Internet infrastructure shows bumps in Nginx and Microsoft Azure usage. All your pages are belong to them
|
|
|
|
|
Unfortunately the actual NetCraft[^] data doesn't present such a rosy picture. The expansion of IIS is limited to low volume/idle sites. The active and 1M biggest site lists show MS has remained flatlined at a ~12% for the last two years while Nginx continues to eat away at Apache's share.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging 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
|
|
|
|
|
Yeah, I kinda figured there might be some creative statistics involved. Also, I can't see IIS taking from Apache, but other things chopping into Apache. People aren't *that* likely to move away from Linux hosting.
TTFN - Kent
|
|
|
|
|
I have never been convinced by TDD myself and I have expressed my opinions on the subject repeatedly in the past (here and here for example) so I can’t say I’m unhappy to see this false idol finally being questioned seriously. In my day, our code crashed, and we liked it!
|
|
|
|
|
In the article TDD is dead. Long live testing. and a subsequent response The pitfalls of Test-Driven Development, both authors, in my opinion, are missing the mark by a mile. In the real world, walking into an existing code base, the reason you need TDD (but can't use it) is because programmers didn't spend sufficient time on good architecture practices, resulting in code that is an entangled morass of intertwined concerns, and yes, as one of the author's points out, because the code itself was never intended to be tested except through, at best, acceptance test procedures (most likely the pen and paper variety -- with the developer watching in the background hoping he rolls a 20.) There is an overall lack of attention paid to designing a component with sufficient abstraction that it can accommodate changing requirements, and little or no attention paid to separating (decoupling) the behaviors between components such that component A shouldn't ever care about what component B is doing. We have a philosophy of refactoring with "just get the minimum to work" to blame for that -- the days of thinking about architecture and abstraction are long gone.
The metaphor of building a sky-scraper is inaccurate because anyone building a sky-scraper would know that you can't make the walls of the first floor so weak that they can't support a second floor. Except it is accurate because, not paying attention to the requirements and living in a "do the minimum work" philosophy, promoted by the likes of Kent Beck's Extreme Programming and Martin Fowler's refactoring philosophies, this actually is exactly what ends up happening, and thus TDD is an absolute necessary fallout of a broken coding paradigm. A more accurate metaphor would have been, the requirements called for a single story building, then the requirements changed. Again, with sufficient abstraction up front, the straw-bale walls could be replaced with titanium reinforced hay quite easily.
As for Rails (or rather Ruby, or rather any duck-typed language), TDD is again essential because duck-typing allows for variances in the behavior at runtime, both of type and function calls. The non-strictness of duck-typing is leveraged in lieu of good object-oriented design--why create sub-classes when I can just pass in an instance that quacks just like the other "ducks." While object-oriented programming cannot be done well without object-oriented design (and yes, I've seen both the "P" and the "D" done horribly and have done it horribly myself) a duck-type language allows the programmer to completely eliminate the "D" -- class, method, quack, quack. Perhaps we should take a clue from the name, "duck-typing", that it is actually quackery, and like medical quackery, promises rapid "feel good" development that you end up paying for in little fragments of time running unit and integration tests because you didn't do the necessary up front design, you haven't clearly abstracted how the rules are handled, you haven't clearly decoupled the behaviors of complex systems to identify the dependencies (which all complex systems will have.) If you add up all the time spent running those tests (which of course spawned whole new technologies to run those tests faster and faster) you will discover that over the lifetime of the product, you spent far more time watching little green bars (or red ones) than you would have spent on solid up-front architecture, particularly in the areas of abstraction. But nay, it quacks, and it's fast. At first.
As for "the industry's sorry lack of automated, regression testing", here, let's not blame the programmer directly even though they consistently over-promise and under-estimate, but rather, let's blame a culture, yes, starting with "the geek" but also placing responsibility firmly on the business practices of management and the continually demonstrated lack of understanding of the importance of regression testing, and the time & cost that developing regression tests and even more costly, maintaining those tests, requires. As with essentially all other aspects of our society, we are living in a constant tension between short-term gains and long-term investment (TDD can be considered an investment) and we all know which side is winning. We have a culture that rewards quick results and punishes the methodical and (seen as) slow thinker. Some of this may be justifiable due to market pressures and real budgetary constraints, but what is lacking is the consciousness to balance planning and activity. So what we have instead is a knee-jerk culture oriented to quick results (Extreme Programming and Refactoring) which, to support a broken development paradigm, demands TDD as the "fix", but nobody seems sees that.
When one of the author's writes "I have yet to see a concrete illustration of how to use Test-Driven Development to test a back-end system interacting with a 20-year-old mainframe validating credit card transactions" I laugh because I have done just that -- CC validation systems all have the means of simulating transactions, it's actually trivial to write TDD's against such systems. Yes, the author does have a point that much of the "...source code [encountered in legacy systems]...was never designed to be tested in the first place...", but again, that's missing the point -- TDD is clearly the wrong tool for those systems. TDD works best in an environment:
- lacking architecture,
- most likely using duck-typing languages,
- and, most importantly, one that has started from ground zero with testing as one of the coding requirements.
This is independent of whether it's a 200 line gem (as in Ruby library as opposed to a "great thing") or a 100 million line application. If those 100 million lines were written with the intention of being unit / feature tested, then there is no problem. Except that it's TDD and probably not well architected out of the gate. And let me be clear that TDD, when applied to a well architected application, is a perfectly valid and beneficial practice, but then TDD is also simplified because it ends up testing behaviors, not architectural flaws and geese trying to pretend to be ducks.
So, is the failure TDD? No. The failure is in a culture entrenched at all levels of software development that says that Extreme Programming and Refactoring can replace thinking and it's brothers "design" and "planning." We have Kent Beck and Martin Fowler (I commit sacrilege in criticizing the gods) to squarely blame for that "regression", excuse me, "story." And it's those two aspects (pun intended) of programming that should be given the boot, not TDD, which has a validity in and of itself under the right conditions.
modified 11-May-14 18:40pm.
|
|
|
|
|
Mango zitango! You're only two sentences short of an article there.
Marc Clifton wrote: The failure is in a culture entrenched at all levels of software development that says that Extreme Programming and Refactoring can replace thinking and it's brothers "design" and "planning."
Bless you.
TTFN - Kent
|
|
|
|
|
Kent Sharkey wrote: You're only two sentences short of an article there.
Well, you hit a nerve, especially since I just came out of a two day intensive pair-programming sessions where all of these issues were rearing their ugly heads (quite subtly, mind you) but after write that monster, I realized I needed to put it on my blog.[^]
Kent Sharkey wrote: Bless you.
Did you know that I'm now an ordained minister? No, of course not. Through one of those "we ordain anybody" websites. I can now officiate your wedding or your death (is there a difference???)
Marc
|
|
|
|
|
Amen to that!
A hammer is a great tool, but it won't help when you need to take the screws out...
|
|
|
|
|
tl:dr
...ok, I did a bit and I agree that Agile development using TDD is a bad idea. I always thought Agile/Scrum was good for Project Management but Extreme Programming and TDD was going too far.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Oh gosh, I wish I'd said that!
Currently stuck in a situation where "we should be doing TDD - so we're going to write tests from now on" has me tossing up between shaking my head ruefully and crying.
Is it only the software industry where techniques, patterns etc. are continually belittled by people either not using them at all, or at least not using them properly?
If I hear one more person say "Oh, we tried <scrum|agile|tdd|di|mvvm|wpf|...> at my last company, and it was just a waste of time because (reason.summary == "We did it wrong") I swear I will put a GOTO in the next piece of code I write.
When builders first built walls with bricks and mortar, did they sit around slagging off bricks because they just slowed you down and the walls were wonky?
|
|
|
|
|
While discussions about tech bubbles have been heated, few commentators seem to be targeting their invective at the real underlying bubble: the World Wide Web itself is crumbling. "Who is the greater fool, the fool or the fool who follows him?"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
