|
Microsoft is today opening a research lab in Manhattan city that aims to benefit from interaction with the academic and tech communities in the metropolitan area, as well as attract new talent to Microsoft, the company said. Most of the initial 15 hires to the lab are researchers from Yahoo Research. [ITworld]
|
|
|
|
|
In this installment we talk to Matthew Brand who, along with Michael Hopke and a few other Champlain College students, recently launched their own game studio. More talk with developers about their backgrounds, projects, interests and pet peeves.
|
|
|
|
|
The best way to improve your systems is by first not doing "dumb things". I don't mean you or your development staff is "dumb", it's easy to overlook the implications of these types of decisions and not realize how bad they are for maintainability let alone scaling. As a consultant I see this stuff all of the time and I have yet to ever see it work out well for anyone. Coffee, cold pizza and clean socks... no, that's what I need to *run* the database.
|
|
|
|
|
I agree with 2 and 3, but not so much with 1.
I have designed databases specifically to hold images and files and I'll probably do so again. His comment "access to the files now requires going through your app and DB layers" is exactly why I choose to store files in a database. There are other reasons to do so as well.
But, it's still a matter of using the right tool for the right job -- you need to really think about what you're doing.
|
|
|
|
|
I don't fully agree with any of them.
1) If the files are of a sensitive nature, store them in a database. It simplifies the security model. Also, if backups are an issue, store them in a different database than the one you backup more frequently. Other files that don't require security (e.g., images) can obviously go wherever, though a CDN is ideal.
2) At my job, we sometimes have to restart the servers because of various issues. Storing session to a database makes it possible for users to retain their session state (so they don't, for example, have to log in again). Storing session out of process might work in some cases, but not if the machine must be restarted. Still, would be nice if we didn't have such finicky servers. *grumbles*
3) I love logging. At my last company, we HAD to log pretty much everything so the data could be audited later. Databases are the perfect place to store logs. If performance is an issue, one can easily store logs on a different database that may even be on a different server. And one should of course abstract out the medium the logs are stored to, so that medium can be changed later. Some employees at my company decided to email every error that happens on our site, but they are so numerous that they are ignored and email is hardly useful for aggregating data (would be nice so we could show which of our servers are most error prone). If we had a proper abstration in place, we could just switch from email to a database. And if we started to log a ton, we could use that abstraction to defer to a queue that bulk inserts into a database.
|
|
|
|
|
My main issue with logging to a database is: how do you log that you can't access the database? I prefer the simplest logging mechanism to avoid as much trouble as possible.
Logs in a file also retain their order even if two entries have the same timestamp.
I write logs as XML, which can easily be imported to a database and analyzed if necessary -- so far it hasn't been.
|
|
|
|
|
That is a good situation a queue would be good for. In the event that logging fails, the queue could keep the logged item and retry later. Or it could write to an alternate medium, such as the file system, email, or the Windows event log. However, logging is not always that essential and not many people put that much effort into it, so it seems like it'd be acceptable to just drop the log event as it'd probably obvious when a connection to the database cannot be made.
Another useful reason to store to a database is when there are multiple servers, such as in a load balanced scenario. Rather than having to remote into each computer, which requires developers be given access to those machines, they can just query a single database. Another situation where logging to the file system would be less than ideal is Azure, as I'm not even sure if you can inspect the file system without writing code to do so and Azure makes no assurance that files will be retained (if the machine goes kaput, the deploy package will be sent to a new machine).
And regarding order, that can be maintained using an identity field.
|
|
|
|
|
AspDotNetDev wrote: a queue
But then how do you log that the queueing system is broken? 
AspDotNetDev wrote: an identity field
Remember who you're talking to.
I'd say that's the wrong tool for the job, or perhaps the wrong job for the tool. I don't (willingly) use identity columns, and I certainly wouldn't for information that is just going to be cleaned out after some period. An identity (or sequence) column on a log table would likely max out much more quickly than one on a customer table, for example.
|
|
|
|
|
PIEBALDconsult wrote: An identity (or sequence) column on a log table would likely max out much more quickly than one on a customer table
There aren't enough hard drives in existence to max out a bigint identity field. 
PIEBALDconsult wrote: But then how do you log that the queueing system is broken?
If you want to account for that, log to an alternative medium (e.g., log file).
But then, what do you do when the alternative medium is broken (e.g., some process locks the log file or deletes the containing folder)?
|
|
|
|
|
I agree with your agreement. Not so much with #2 though. What the author calls ephemeral data, usage stats, metrics, etc. The reason to store such information is to be able to analyze it. It is a matter for architecture and design of an application as to what is necessary and what is not.
Failure is not an option; it's the default selection.
|
|
|
|
|
I wouldn't take this piece too seriously. There are no hard and fast rules for what you store in a database - you make the decisions based on the job at hand.
Also I disagree in a big way with point 1 - it's perfectly fine to store images and files in a database. And in fact you should do so in many cases - because you get transactions, rollbacks, atomic operations etc. Also, when you back up, you have your files as well - rather than having to copy files from an arbitrary folder from one server to another.
|
|
|
|
|
Oh man. Not another one of these "my advice for my type of work is gospel and works for everyone" type articles.
1. Storing BLOBs is sometimes the *only* practical option you have.
2. What if your ephemeral data generates, itself, important data that is persisted? A crude example is session data: storing it in a database means that when things are weird you can perform sll sorts of queries on the sessions and spot malicious activity
3. I don't even know where to start on this one other than to say that if you want to store logs in flat files then why are you storing them at all. If your logs are small enough that you can manually scan them every day then fine, but if you have serious data then log only if you need to, and the #1 reason to log is so you can search the logs later, and, well, that's what a database is really, really good for.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Chris Maunder wrote: you can perform sll sorts of queries
Sounds... er... efficient.
|
|
|
|
|
I have been saddened and, yes, angry, about the recent trend in the JavaScript community; to throw away the best practices we have spent a long time honing in what, to my eyes, is an act of machismo; a revolt against good engineering practices for the sake of revolting rather than to make the world a better place. You're doing it wrong. Or are you?
|
|
|
|
|
But many "best practices" are not even good practices. (Though none come to mind at the moment.)
|
|
|
|
|
This reminds me of the time when the jQuery plugins site was completely obliterated.
And how I just fixed some SQL injection vulnerabilities created by another developer.
People don't follow best practices. They follow quick and easy (and failure prone) practices.
|
|
|
|
|
"Here’s the thing about best practices: at the point at which you become sufficiently experienced, you understand why they are good and so can choose to not use them as the situation allows."
I think this is a key point. You are not blindly following a practice because someone else says it is good to do so. You need to understand the practice and be able to evaluate it in a given context.
Failure is not an option; it's the default selection.
|
|
|
|
|
Very well stated, Mark. I wanted to make the same comment. If all you do is best practice, mediocrity is the best you can hope for.
|
|
|
|
|
In March I wrote about some of my least favourite parts of CSS. Admittedly, that was a pretty negative post, and I’ve even slightly changed my opinion of a few of those things, thanks to the comments. But I like CSS a lot. So as a follow-up, I thought it would only be fair to list some of the things in CSS that I think work very well and thus are valuable to know and use often. Which parts do you like... or hate?
|
|
|
|
|
After Harry Roberts published his HTML/CSS coding style I’ve decided to follow his call and write down how I like to code and what my guidelines for HTML and CSS coding are. Please let me know if you think that there are ways to do certain things better or in a more understandable way. Style guides are always controversial. What do you think of this one?
|
|
|
|
|
CSS3 has some new values for sizing things relative to the current viewport size. It's shipping in Chrome 20 (canary at the time of this writing). And not behind a flag, it just works. Why is this awesome? There is a such thing as a comfortable line length for reading text on screens. But other reasons as well. Read on to find out more. So you can read this whole line on any platfo....
|
|
|
|
|
Relax, Dr Evil. Your inspired request for “sharks with frickin’ laser beams attached” has finally been fulfilled in the real world. Yeah, baby, yeah!
|
|
|
|
|
The Football Manager series is one of the world’s most popular gaming franchises, and no-one could deny that its iOS version has been a success. The recently released Android version, though, isn’t doing quite as well, with studio boss Miles Jacobson claiming that, at last count, the piracy rate for his game was at 5:1 in favour of illegally acquired copies. Stand and deliver: your apps or your devs!
|
|
|
|
|
With the release of their BlackBerry 10 beta development tools and Dev Alpha devices earlier today, RIM has made it very clear that they want to build up as much developer love as possible before BlackBerry 10 officially launches. Well, as it turns out, that’s not the only thing they’re doing to attract devs. Ah, but there’s a catch (isn’t there always?).
|
|
|
|
|
Windows Live was first announced on November 1st, 2005. Since that time, we’ve been hard at work building software and services that deliver that promise, a foundation that we could rely on as we designed new versions of Windows as well as other Microsoft products. Windows 8 is a chance for us to act on that feedback and reintroduce you to the broadest and most widely used collection of services on the Internet. Windows Live is dead... Long live Windows Live!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
