Again, I agree to an extent... However some decisions up front can be just plain bad... for example, querying a database, pulling a fairly complicated set of joins for a result set, then only using 2 fields because the procedure already existed, to augment this information in a loop, where another query is made for each iteration, that now pulls more information across the wire to use three fields instead of a simpler query with a left join.
I've seen many times over where a convention is used, and a result takes > 3 seconds that should take a fraction of a second. I know that even then it's not so bad, but I am tired of seeing unresponsive web based applications that are only that way because of poor coding choices. Not even getting into passing dates, uuid's, and numbers as strings. It's not rocket science. Simple, poorly written line of business apps. As much as I may prefer one framework over another, the types of bad choices I see happen over, and over again.
A lot of this doesn't come down to premature optimization, a lot often comes down to using certain design patterns, or conventions where they don't belong. Right now, I'm reviewing an application using a typical entity/dal/bll separation, with stored procedures behind the bll. A lot of whats in place is a literal crap ton of translation layers, often for tabular data that doesn't really even fit the enitities defined well, tis isn't "MS Entity Framework" nut hand code.. The entire BLL goes straght to the DAL, which in turn often calls a sproc... most sprocs are only used one place. A really simple web app that should have taken less than 3 months is now at month 8, and still has a ton of bugs, and unfinished work. A simpler DAL for the db calls from the application without the entities, and/or bll would have been simpler, easier to maintain and taken less time. Many of the SPs are really simple queries that imho didn't need t be broken out like they were (that's a dba v. dev argument though).
I've seen similar issues in using ORM tools religiously, where breaking out of the ORM is often prudent.
Honestly, I agree to an extent, but there is a need for a deeper understanding. I'm more than happy to use generics or other higher language conventions, hell, I like JavaScript of all things... The flip side is, I see more poor performance issues because of lack of understanding as well as errant behavior because of misuse of static resources than I care to look back on.
I was working on the start of a multi-simulation engine meant to run server-side. The in-place developers were gearing towards each avatar having it's own thread... okay, now take 1000+ avatar processes per simulation (1 sim per user) for a thousand or so users, and see how well that works. The constraint here wouldn't be memory usage, but the swapping of resources for a million+ threads. Let alone the IO to data storage, and the interaction messages.
Understanding your platform, a bit of history and some lower level knowledge is very important to making better decisions to start with. Which isn't the same as premature optimization.
I think without terminal (one step at a time) input/output it's harder to be deterministic in terms of state. I think that functional languages tend to have a leg up here. I do feel that the next few years will get very interesting. One trend towards the highly parallel, and others towards the higher non-blocking IO throughput. It willbe interesting to see what platforms emerge as a result.
ROFLMAO.... Funny, I've written a handful of jQuery extensions, just to work around certain issues, and knowing about the nasty implementation details was necessary. It's generally a good idea to understand what goes on underneath. I've had several times where understanding threading, and pointers has helped even when working on improving the performance of C# based applications. Developers who don't understand under the covers make stupid choices in ignorance. I don't like working close to the metal, I'm not that good with C, assembly, C++ etc... though having at least a general understanding helps a lot in developing applications in higher level languages.
The same is very true with JavaScript, and especially with platforms like NodeJS and MongoDB gaining in popularity (yeah, I'm a fan). Not understanding that string concatenation is far slower in most cases than array joins can be a huge difference (not as much in V8, as it does a better job in compilation, but still).
Said drawback wrt patents don't protect you when writing inC++, or Python either... with Mono, if all you want are Linux apps, you have GTK# and other options. Though gtk, and many other options are rather alien on other platforms, it does work pretty well. The patent wall here is pretty FUD driven. No significant software project is safe from patents... period, which is why the solution is to abolish software patents in the US, and push back against them globally.
I'm quite familiar with the PITA that JNA is thank you... P/Invoke calls in.Net are much more straight forward imho, and the are gen tools similar to JNA if you need to expose more of an underlying api.
Well, Pinta is pretty impressive, and Tomboy's popularity spawned a huge fud-driven effort to create a non-mono version. I worked on a kiosk system using mono + castle-activerecord + firebirdsql + gtkmozembed for the UI... worked really nicely, running on an AMD embedded x86 platform, I forget the specifics, but it worked really well for our usage.
Well, if you're judicious, your code will run just as well in many platforms via Mono... as a tool to ease development of windows apps alone would probably be enough, combined with VS, it does that quite well.
I'm personally hoping to see more proliferation of NodeJS and MongoDB, so you may well consider me a nutter.
Sheesh, what a FUD trip this is.. there are non-MS implementations of.Net that are open-source and support cross platform migration as easily as any other managed runtime. As to TFS regarding not being able to access the system API, the author doesn't know WTF they are talking about. The ability to interact with system libraries is far easier in.Net than any other managed platform, even in a platform agnostic way.
It's the frikken Javascript crap that's trashing users' computers left and right and they are invariably running MSIE when it happens.
If you wouldn't mind pointing out how Script engine exploits for the past 5 years or so have been worse than their major counterparts? It's been my understanding that Flash, Acrobat Reader and Java have been the main attack vectors, and this isn't limited to windows, or a specific browser. Don't get me wrong, having scripts run in email, let alone having it run in the "local" not the "untrusted" zone was a very stupid move in outlook and oe, but it really ism't 1999-2000 anymore.
It's the sites/services actively working to continue supporting IE6-7-8 that are the problem... We should all push the yellow banner at the top to older IE users. Like the 20 things I learned site does... same for firefox 3.5, and older safari and opera versions.
You can however always rest easy knowing that their implementation of any security product will be so-so at best. If you have a great idea and a great implementation even winning the MSDN subscription will net you a profit in the long run by licensing to others. The free press is also worth an amount, even if it can't be calculated or measured.
Seeing that their Security Essentials is better that the other free options, and many paid options, that may be bias speaking.
Fair enough... I live in a state where only one party requires notice for recording a call, me being that party should allow it... I have no desire to do so, but would be nice.
What I'd really like is to be able to create a.zip file, with an extension htmlz, or.htpkg or something that has an index.html inside of it as a default point... then have browsers support packagename.htpkg#!/somefile.ext where they request packagename.htpkg, and use that archive for the files within it... That way you can have archived sets of files, html, css, javascript, images etc as a single control set that can be used for in/out of browser usage.
When Adobe first bought Macromedia, I was really hoping that Flash would morph into a container of standards based.svg files, mp3 files, and markup/script files that are interpreted from a contained package. I know that AIR html apps does this, and Silverlight apps do this, even.docx and.odt etc do it.
I don't get why there isn't a standard application package format for html/web applications that has wide browser support. A single request/cached file that can be more readily sandboxed than even a typical website, as it should be expected to be contained, and only communicate via websockets (or some other open communication point).
Just would be nice to see... with a flash advert, like them or hate them, it's just one download.. with canvas ads, you have the html file (iframe?), followed in with the scripts, image resources, etc... yes, this can be inlined with base64 encoding, bloating things out a bit, but still not as smooth as a packaged format standard would be.
Slashdot Mirror
I thought the same... though PERL is great for one thing... text data processing, like logs.
This is why I've been following NodeJS with great interest...
Again, I agree to an extent... However some decisions up front can be just plain bad... for example, querying a database, pulling a fairly complicated set of joins for a result set, then only using 2 fields because the procedure already existed, to augment this information in a loop, where another query is made for each iteration, that now pulls more information across the wire to use three fields instead of a simpler query with a left join.
I've seen many times over where a convention is used, and a result takes > 3 seconds that should take a fraction of a second. I know that even then it's not so bad, but I am tired of seeing unresponsive web based applications that are only that way because of poor coding choices. Not even getting into passing dates, uuid's, and numbers as strings. It's not rocket science. Simple, poorly written line of business apps. As much as I may prefer one framework over another, the types of bad choices I see happen over, and over again.
A lot of this doesn't come down to premature optimization, a lot often comes down to using certain design patterns, or conventions where they don't belong. Right now, I'm reviewing an application using a typical entity/dal/bll separation, with stored procedures behind the bll. A lot of whats in place is a literal crap ton of translation layers, often for tabular data that doesn't really even fit the enitities defined well, tis isn't "MS Entity Framework" nut hand code.. The entire BLL goes straght to the DAL, which in turn often calls a sproc... most sprocs are only used one place. A really simple web app that should have taken less than 3 months is now at month 8, and still has a ton of bugs, and unfinished work. A simpler DAL for the db calls from the application without the entities, and/or bll would have been simpler, easier to maintain and taken less time. Many of the SPs are really simple queries that imho didn't need t be broken out like they were (that's a dba v. dev argument though).
I've seen similar issues in using ORM tools religiously, where breaking out of the ORM is often prudent.
Total tangent, been a really frustrating day.
Honestly, I agree to an extent, but there is a need for a deeper understanding. I'm more than happy to use generics or other higher language conventions, hell, I like JavaScript of all things... The flip side is, I see more poor performance issues because of lack of understanding as well as errant behavior because of misuse of static resources than I care to look back on.
I was working on the start of a multi-simulation engine meant to run server-side. The in-place developers were gearing towards each avatar having it's own thread... okay, now take 1000+ avatar processes per simulation (1 sim per user) for a thousand or so users, and see how well that works. The constraint here wouldn't be memory usage, but the swapping of resources for a million+ threads. Let alone the IO to data storage, and the interaction messages.
Understanding your platform, a bit of history and some lower level knowledge is very important to making better decisions to start with. Which isn't the same as premature optimization.
I think without terminal (one step at a time) input/output it's harder to be deterministic in terms of state. I think that functional languages tend to have a leg up here. I do feel that the next few years will get very interesting. One trend towards the highly parallel, and others towards the higher non-blocking IO throughput. It willbe interesting to see what platforms emerge as a result.
I wish there was a-1 for use of PHP mod... ;)
For Chrome users, see KB SSL Enforcer.
ROFLMAO.... Funny, I've written a handful of jQuery extensions, just to work around certain issues, and knowing about the nasty implementation details was necessary. It's generally a good idea to understand what goes on underneath. I've had several times where understanding threading, and pointers has helped even when working on improving the performance of C# based applications. Developers who don't understand under the covers make stupid choices in ignorance. I don't like working close to the metal, I'm not that good with C, assembly, C++ etc... though having at least a general understanding helps a lot in developing applications in higher level languages.
The same is very true with JavaScript, and especially with platforms like NodeJS and MongoDB gaining in popularity (yeah, I'm a fan). Not understanding that string concatenation is far slower in most cases than array joins can be a huge difference (not as much in V8, as it does a better job in compilation, but still).
Said drawback wrt patents don't protect you when writing inC++, or Python either... with Mono, if all you want are Linux apps, you have GTK# and other options. Though gtk, and many other options are rather alien on other platforms, it does work pretty well. The patent wall here is pretty FUD driven. No significant software project is safe from patents... period, which is why the solution is to abolish software patents in the US, and push back against them globally.
Pinta seems to run fine on my mac, and in linux... *shrug*
I'm quite familiar with the PITA that JNA is thank you... P/Invoke calls in .Net are much more straight forward imho, and the are gen tools similar to JNA if you need to expose more of an underlying api.
Well, Pinta is pretty impressive, and Tomboy's popularity spawned a huge fud-driven effort to create a non-mono version. I worked on a kiosk system using mono + castle-activerecord + firebirdsql + gtkmozembed for the UI... worked really nicely, running on an AMD embedded x86 platform, I forget the specifics, but it worked really well for our usage.
Actually MS has been demoing Windows 8 on ARM, and would predict that a lot f the higher layers of the UI utilize .Net for application logic.
I think that what you mention will be the case for Windows 8 on ARM.
It's used a lot in web and line of business apps. It is pretty much a split market with Java and .Net for business web apps.
As to a killer app, try paint.net or pinta.
Well, if you're judicious, your code will run just as well in many platforms via Mono... as a tool to ease development of windows apps alone would probably be enough, combined with VS, it does that quite well.
I'm personally hoping to see more proliferation of NodeJS and MongoDB, so you may well consider me a nutter.
Sheesh, what a FUD trip this is.. there are non-MS implementations of .Net that are open-source and support cross platform migration as easily as any other managed runtime. As to TFS regarding not being able to access the system API, the author doesn't know WTF they are talking about. The ability to interact with system libraries is far easier in.Net than any other managed platform, even in a platform agnostic way.
It's the frikken Javascript crap that's trashing users' computers left and right and they are invariably running MSIE when it happens.
If you wouldn't mind pointing out how Script engine exploits for the past 5 years or so have been worse than their major counterparts? It's been my understanding that Flash, Acrobat Reader and Java have been the main attack vectors, and this isn't limited to windows, or a specific browser. Don't get me wrong, having scripts run in email, let alone having it run in the "local" not the "untrusted" zone was a very stupid move in outlook and oe, but it really ism't 1999-2000 anymore.
It's the sites/services actively working to continue supporting IE6-7-8 that are the problem... We should all push the yellow banner at the top to older IE users. Like the 20 things I learned site does... same for firefox 3.5, and older safari and opera versions.
You can however always rest easy knowing that their implementation of any security product will be so-so at best. If you have a great idea and a great implementation even winning the MSDN subscription will net you a profit in the long run by licensing to others. The free press is also worth an amount, even if it can't be calculated or measured.
Seeing that their Security Essentials is better that the other free options, and many paid options, that may be bias speaking.
Nice idea.. Picassa integration alone is a huge +1
Brilliant!
Fair enough... I live in a state where only one party requires notice for recording a call, me being that party should allow it... I have no desire to do so, but would be nice.
What I'd really like is to be able to create a .zip file, with an extension htmlz, or .htpkg or something that has an index.html inside of it as a default point... then have browsers support packagename.htpkg#!/somefile.ext where they request packagename.htpkg, and use that archive for the files within it... That way you can have archived sets of files, html, css, javascript, images etc as a single control set that can be used for in/out of browser usage.
.svg files, mp3 files, and markup/script files that are interpreted from a contained package. I know that AIR html apps does this, and Silverlight apps do this, even .docx and .odt etc do it.
When Adobe first bought Macromedia, I was really hoping that Flash would morph into a container of standards based
I don't get why there isn't a standard application package format for html/web applications that has wide browser support. A single request/cached file that can be more readily sandboxed than even a typical website, as it should be expected to be contained, and only communicate via websockets (or some other open communication point).
Just would be nice to see... with a flash advert, like them or hate them, it's just one download.. with canvas ads, you have the html file (iframe?), followed in with the scripts, image resources, etc... yes, this can be inlined with base64 encoding, bloating things out a bit, but still not as smooth as a packaged format standard would be.
Oh, like email?
I tend to think the same thing when I see bank teller behind bulletproof glass.