Matt Cutts has been trying something new or giving something up for 30 days at a time. First he tried to do 10k steps every day, then he gave up TV and now he’s biking to work at the Googleplex – each one for the 30 days.
As he says, 30 days is long enough to build a habit. I’m trying out his idea and I’m not eating chocolate for the whole of July.
Relational databases, such as MySQL, PostgreSQL and various commercial products, have served us well for many years. Lately, however, there has been a lot of discussion on whether the relational model is reaching the end of its life-span, and what may come after it.
Should you care? Which database technology should you be using?
http://thinkvitamin.com/dev/should-you-go-beyond-relational-databases/
Ron Jeffries of XP fame:
“If I’ve got six months to build a system, then I’ll spend six months building it. I’ll also spend six months designing it, and another six months testing it. The good news is that it’s the same six months”.
Seems like the best (and obvious) thing, right? Build the design based on your knowledge, which you acquire as you work on the project and encounter problems and design choices.
But begs the question: Is there a place for an Architect in an Agile environment and is there any value in an architecture document?
An architecture document is a system design that answers key design problems and breaks the system down into manageable and extensible components. I’ve worked on big arch documents in the past when working in waterfall environments – looking back, it’s easy to see that we spent a lot of time agonizing over design decisions that couldn’t be properly answered until much of the code was written. So continuous design is good.
But how do you document it in a continuous fashion? We used to create Word documents but that seems like too much work if you are going to be changing it often as you will be re-arranging the document all the time. A Wiki? Some bespoke Agile tool? UML tool?
Or do you not document it at all? Is Javadoc (or your language’s equivalent) enough along with some auto-generated class diagrams? Perhaps the test cases will document the functions of the system and avoid the need for Sequence diagrams? After all, once the code is done, the tests pass and the system is released, what’s the architecture design document for? It can only be a reference tool for people coming onto the project later on.
Many people have said that an Agile design document should have “Just enough in it to get the job done”. Great in theory but a tough one to do – what’s just enough?
I love Python, Ruby is great and PHP is OK – dynamically typed interpreted languages have their place. But this cartoon really nails the difference between the cool web2.0 three-man coding shops and the enterprise environment.
Not sure why I found it funny, but I did. Was reading Stack Overflow today and someone had asked a question about managing an object pool. One answer was, “use the Multiton pattern”.
Has a design pattern ever sounded more like a character from Pokemon?
Even though it has a comedy name it does have a legitimate use – whereas a Singleton holds once instance of an object a Multiton holds a specified number and thus creates an object pool. Wikipedia has an example.
It’s a safe guess that somewhere at Merck today someone is going through the meeting minutes of the day that the hair-brained scheme for the Australasian Journal of Bone and Joint Medicine was launched, and that everyone who was in the room is now going to be fired.
The Scientist has reported that, yes, it’s true, Merck cooked up a phony, but real sounding, peer reviewed journal and published favorably looking data for its products in them. Merck paid Elsevier to publish such a tome, which neither appears in MEDLINE or has a website, according to The Scientist.
Original article in full here.
The research report, “Online Catalogs: What Users and Librarians Want”, came out recently. Authored by an OCLC research team headed by Karen Calhoun, Vice President, WorldCat and Metadata Services, the report presents findings about the data quality expectations of catalog end users and librarians.
From the news brief, the Online Catalogs report offers:
· Insight for readers seeking to define requirements for improved catalog data
· Information about the metadata elements that are most important to end users in determining if an item will meet his or her needs
· Support for the enhancements end users and librarians would like to see made in online library catalogs
· Insight into the end user’s discovery experience
· Findings for readers in areas associated with contributing, synchronizing or linking data from multiple sources in library catalogs and integrated library systems
