The PDO extension… that might be an interesting extension to get to know thoroughly, along with whatever MySQL driver sits underneath it. Since where I work is a PHP/MySQL shop with large enterprise database usage, I should think it would be in my company’s best interest to have this knowledge in-house as well. I had already planned on learning a lot more in the way of MySQL design, tuning, and internals. The PHP driver might just be an interesting place to start.
An excuse to dive back into C-based device driver development and/or support, all in the name of PHP… how cool is that? Nice!
The bug list does appear substantial. Bookmark: PHP Bug tracker for PDO and friends.
A generation ago, the standard answer to any Unix question was “read the man page.” Before I explain how this relates to learning PHP Internals and about PHP Extensions, I should explain what a man page even is! The old school answer would be, “read the ‘man’ man page.” These days it’s explained on Wikipedia: http://en.wikipedia.org/wiki/Man_page.
On Unix, and to a large extent Linux, most everything is documented in the man pages: Command usage, library usage, system calls, header files, utilities, even (eventually) some tutorials.
Unix (and therefore Linux) and arrogance go together. Larry Wall, the creator of Perl, calls it hubris, and declares it to be a mandatory trait. Time after time, the standard (and correct) answer is “It’s in the man page.” It may take you several days to figure out which man page to go read; that fact was both assumed and expected. No self respecting Unix guru will waste his or her time with someone incapable of figuring out which man page to read; and all Unix gurus are self respecting.
Dilbert, 20 years ago, learned it this way: http://dilbert.com/strip/1995-06-24. The comic is so spot-on that the standard modern text on deep-down Unix programming has the comic on the book’s front cover (see above right)! There’s a third edition out, so if you follow my link, be sure to flip to the more recent edition before you buy the book. If you need to program with pthreads, named pipes, and other Unix/Linux system calls, you’ll be familiar with that book.
So what does this have to do with PHP Extensions? Bear with me; we’re getting there.
Read more…
The slide deck is here: http://www.slideshare.net/auroraeosrose/php-extensions-45834933. Elizabeth Smith’s talk page for the event is here: https://joind.in/talk/view/13836.
On the right hand column of the slide share page is a list of related slide decks, with several on PHP extensions and PHP internals.
This was my first-ever PHP conference, gathering, or meet-up. I intended to keep an open mind and hope for the best. Fortunately, I was pleasantly surprised.
For the past many months, I’ve been reflecting on “software craftsmanship.” I’ve studied numerous ways to improve my practice of the art. Does “software craftsmanship” even apply to the PHP world? The published books generally refer to the Java world, for example, the Clean Code series by “Uncle Bob” Martin.
In the PHP world, where does Software Craftsmanship or a Pursuit of Excellence fit in the paradigm of getting the code into production? What’s important? What is not?
I’m coming to realize that I am not asking the right question.
Read more…
Others may have a better solution to this issue. I welcome suggestions. Meanwhile, here is my plan.
I have a Family Tree Maker database. It’s inside my copy of Family Tree Maker for Windows 2014. It’s also linked to an online tree at Ancestry.com.
When I get updates from other people, the normal procedure is to re-type the information. Merging information is ALWAYS a bad thing. However, I’m now faced with a different situation: Transcribing our paper and manuscript information into Family Tree Maker. Read more…
You have seen the Ancestry.com commercials about exploring your identity. Great! Where to start?
At this point you need to consider your customer requirements, where YOU are the customer. What’s your level of interest? How deeply do you want to dive? Do you want to connect with other relatives’ information? Read more…
This is a consolidation of the “Second Design” posts into a single document. It’s the same text, just put together into a single page for convenience. If I do any editing, it will be to THIS document.
Read more…
Categories:
Data Design Tags:
The User Experience
Our data design centers around these features:
- How/where does this item fit into the Strong genealogy? Internally we discern this with the Dwight classification number.
- From this item, we can click to the Langbehn Database, which allows us to explore the early Strong genealogy and family relationships.
- From a given point in the Langbehn Database (or anywhere else, for that matter) we can bring up links to all related resources we have online with the SFAA.
- We can create a master names list as the alternate way of exploring the above.
I don’t think we need to design in any advanced searching capability. That can come later as experience warrants. The Langbehn Database does have advanced search capability.
Read more…
Categories:
Data Design Tags:
Other GEDCOM Database Files
If people submit genealogical information to us, they may be able to submit it in the form of GEDCOM files. All personal genealogy software supports data export to GEDCOM format.
Our TNG software can import any number of family trees (GEDCOM files), including attached images and documents if handled properly.
TNG’s advanced search capability can do searches covering a specific tree, or return results for all trees combined. Thus, rather than creating a huge “master database,” I believe it makes far more sense to maintain distinct trees as submitted. There are very strong reasons for not attempting to combine or merge information (but outside the scope of this document). TNG allows us to keep things intact as submitted, but do combined searches over all trees at once.
Read more…
Categories:
Data Design Tags:
The Manuscripts in Progress
The SFAA Historians worked on updates to our published books, from 1990-2004. I have most of this work in the form of Microsoft Word documents. These documents are organized the same way as the published books. That is, each separate Word document covers descendants of a specific person. Each can be tied to one specific Dwight number and person.
Because these are computer files, I believe that I can mine each document for names. I believe I can catch the name at the beginning of each formatted paragraph, and capture an excerpt such as the paragraph itself.
Since each of these documents was typed by hand, there is a lot of “fuzzy logic” involved in successfully capturing the names. Thus this information would be added to the database slowly, over time.
Read more…
Categories:
Data Design Tags: