Grocery stores around here used to have big trash cans next to the fresh corn because people were continually peeling the leaves back looking for The Perfect Ear and leaving piles of leaves mixed in with the corn. And I guess some people just peeled it clean in the store to avoid doing it at home. Then when the economy went down the shitter they took away the trash cans, put up a sign saying ‘corn shouldn’t be stripped until just before you cook it’. (They also took away the trash cans that used to be out in the parking lots, near the shopping cart carrels. I guess people were smuggling their garbage from home into the store’s trash cans.)
Well, the sign was right. I’ve never understood why people wanted to husk the corn in the store. It’s not as if you’re paying for it by weight. The reasonable thing to do is pull back a little from the top to make sure the ear is full, not wormy, etc., but keep the rest on until you start the water boiling.
If you are really careful you can peel back the husks, get rid of the silk, put the husks back, soak them in water and grill the ears =) then you just have to husk it before eating and not worry about the silk=)
Oh, I am so craving fresh summer sweet corn! Although nothing will ever be the same as when my parents grew corn in their garden. The drill was to turn on the heat on the potfull of water, then go out and pick the corn, shuck it right there in the garden, and by the time you get inside the water is boiling. Plunk. Yum.
I don’t see the problem. The name wasn’t “vegetarian minestrone,” it was “vegetable minestrone,” which means it has vegetables as the primary ingredient. If you bought a bowl of beef soup, would you be upset if it had some vegetables in it? Then why be upset if your vegetable soup has some meat in it?
I Googled Sundays during Lent little Easter and turned up a bunch of hits that all seem to agree with my recollection.
I think **RM **was specifically questioning the Sunday exemption, not the practice of giving something up for Lent.
I’ve got a new one, although I suppose — to be charitable — the folks on the other end of this might be thinking I’M the one who “just doesn’t get it”.
Databases are made up of tables. Tables, in turn, are made up of fields (columns) and records (rows), whereby each field or column contains a type of data (lastname, favorite color, length of last tied shoelace, whatever) and each record or row contains a discrete chunk of data about an entity (Joe Blow’s lastname, favorite color, and length of last shoelace, as opposed to the next record which is Suzy Smith’s data).
In FileMaker’s relational database structure, different tables can be related to each other in more than one way and in the schematic structure this is accomplished by creating as many aliases (shortcuts for you Windows-centric folks, I guess) to each table as you need: If you already have a relationship between Job and Client based on Client ID in Job equals Client ID in Client, but you now need a connection to Client that represents all the different clients that the Salesperson assigned to this particular job has a history with, or some such thing, you would create an additional TABLE OCCURRENCE of Client: “Clients of SalesPerson” or “SalesClients” or “ClientsViaSales” or some such thing, which would show up on the diagram as if it were a different table.
In actuality, ALL of the tables in the relationship schematic diagram are aliases (table occurrences) even if they are the first / primary ones for that table. And you can name them almost anything you want. (there are a few illegal characters you can’t use like colons and backslashes and math operands such as = and - and +)
Fields WITHIN tables, which can be text fields, date fields, numerical fields, etc, each holding a little chunk of info about Joe Blow or Suzy Smith or whoever, can also have pretty much any name you want to give them.
You’re bored alread, aren’t you? Sorry!
Here’s the gripe: I would use names like THESE:
Table Occurrences
Clients
Jobs
Contracts
SalesContracts
ClientsViaSales
NewJobs
Fields
CreationDate
ModificationTimeStamp
CompanyName
SerialNumber
JobTitle
Status
HERE in contrast are the kinds of names that have cropped up in recent years within the FileMaker developer community, along with some damn silly ways of doing relationships:
TableOccurrences
s137150__var_job__Primary
E_Clients_
E_Clients__to__J_Jobs__pk_n_Serial_Number__to_fk_n_for_Foreign_Serial
sm_uEfK214_JJIMClients_viaJob
Fields
__pk_nAutoSerial
s13712_E_Job_JobName_t
Ab_2e_calc_LastModifiedDate
_fk__num_xJOB.fp7_autoportal_sSerial
No, I did not accidentally just let my kitty cat walk across my keyboard in mid-post. That’s really the kind of naming convention garbage I’ve run into. I kid you not.
They say: “We like to encode information about what the table occurrence represents when we name it”. And “we think it is a good idea to put a lot of metadata info about the field type and whether it is modifiable by users and whether it is used by foreign files in relationships when we name our fields”
I say: Bloody fucking HELL, I like to touch-type my way through scripting and field defs. You obviously select EVERYTHING from menus of existing entities and don’t mind spending 5 minutes fishing around for each of them. NOTHING needs to have that arcane of a naming convention!
Yeesh.
I have never heard of needing proof of address. If I came there to rent a car and provided my UAE (Dubai) Driving license, and a credit card… I’d need proof of address too?
Physical address?
The reason being is that in Dubai there is no home mail delivery so nothing I have has my physical address on it. All bills and bank statements only have my PO box. A few of my friends don’t even have a physical address other than “3rd villa on the right after the Pizza Hut” or similar directions. Even FedEx has to call to get directions as the physical address system is broken.
Great username/post combo.
AHunter3, I feel your pain. I took on a project one time based on a FileMaker database and just about went crazy trying to fit my relational DB experience and terminology into a FileMaker environment. It just doesn’t work. I think FM started out as a flat-file system, and they tried to shoehorn relationships into it, but never did get the concept right.
Au contraire. While FM did indeed start out as a flat-file system, it works quite well as a relational database. I am very fond of their implementation.
It does not share an ancestry with SQL environments such as Oracle MySQL or MS SQL Server, or with other integrated-GUI apps that tried to converge with SQL such as MS Access. But I just finished a 2-month stint with a very experienced Oracle developer who kept saying “I can’t believe how EASY and straightforward FileMaker is compared to SQL”. Once you get used to it (and quit thinking that relational db = SQL by definition), FileMaker is addictively pleasant to work with.
But some blithering idiot wrote some kind of guide or “missing manual” sort of thing that advocated a brain-dead approach called anchor-buoy, which tends to go hand-in-hand with the above-described naming convention from hell.