|
patbob wrote: That was supposed to have happened back when GPS receivers were first being built into smart phones.
Exactly. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
They're right, though.
People who live in a town and drive around a town all their lives are never going to know where they are unless they use Pokemon Go services from google.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I'm looking for quick recipes for yeast-less bread...and I'm looking for proven recipes (I did Google and found some, but I'm looking for something to be trust)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Not quite an answer, but, back in graduate school I used to make such a bread. What I do remember is that (besides no kneading: I believe it was called "NO KNEAD BREAD") it contained eggs (to hold it together) and a bunch of baking soda (to make the bubbles). Not that healthy but I was young and it didn't matter.
Essentially, this was a cake recipe without all of the sugar and spice.
Hopefully the NO KNEAD BREAD will give you another search criterion.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I would think someone in your area might have a good one. Being a dumb American, my first thought was the Feast of Unleavened Bread.
You might ask co-workers if they have a mother / grandmother with one.
Mongo: Mongo only pawn... in game of life.
|
|
|
|
|
Speaking from experience, matza (the Hebrew name for unleavened bread) is not something you want to eat on a regular basis. The only reason we eat it is to remember that we were evicted from Egypt (during the Exodus), and were not given enough time to allow the dough to rise. Hence, we had unleavened bread. 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
What we have around here I done - now I'm looking for something new, but tested...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: I'm looking for proven recipes
If it is 'proven', it must have been proved. To prove bread it must have risen using a rising agent, e.g. yeast.
From (for example) http://www.homemadeloaves.co.uk/2012/08/what-is-proving-and-do-i-need-basket.html[^]:
Ok, so what is 'proving'?
Proving refers to the second rising of the dough - the rise that happens just prior to baking.
The first rise happens almost as an incidental by-product of the fermentation process.
After you've mixed the dough, you leave it to rest for a while to allow the yeast to multiply and start acting on the starches in the flour to produce carbon dioxide gas, which makes the bread rise.
So, in my bread recipes, we have two rising stages. The second one could, technically, be called 'proving'.
|
|
|
|
|
Do you mean unleavened bread ot soda bread[^]?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The problem with time is that it is (of course) different depending on your time zone and daylight savings time for your region.
Scenario 1: Let's say I make a blog entry at 8 AM EST, then I get on an airplane and fly to CA and set my computer to PST. When I look at my blog entry, it probably says that I made the post at 5 AM, but in my thinking, my frame of reference is still "when did I make that post (when I was in NY)?"
Scenario 2: I make a blog entry at 8 AM EST, and you, living in CA, notice my blog entry, which has a time of 5 AM (because you're in PST.) That makes sense to you, in your reference frame, because you know you're 3 hours earlier.
Scenario 3: I run a company that has ATM's (disclaimer: this is a good example, irrelevant to the fact that write software for ATM's, I'm not asking you to solve programming problem in that regard) in local gas stations all over the country. A customer in NY (UTC-5 at some points of the year) calls and says the ATM didn't dispense cash or a receipt! The help desk asks when they did the transaction, and they say, around 8 AM because that's the time in NY. The customer service is in CA (UTC-8 at the moment, we'll customer service in India for this scenario), so what time do they search for? Do they need to ask "where were you?" so they know the time zone and mentally subtract off 3 hours (maybe dealing a 1 AM NY transaction on 1/1/2016 now being seen in CA as 12/31/2015 10 PM????)
So the question becomes, what does the user need to see, and what do they expect to see? When (harhar) does it make more sense to store date/time in the true local time, including timezone (either "PST" style notation, or "UTC-8" notation, for example, keeping in mind that not everyone knows what "UTC" is or even timezone designations like EST, MST, PST, etc. When does it make sense to convert to local time? Should both "my local time" and "transaction local time" be available for displaying/searching?
Am I missing something obvious? Have you had to deal with this issue?
And I haven't even touched the nightmare of daylight savings time.
Marc
|
|
|
|
|
I, once, worked on this project - Noda Time | Date and time API for .NET[^] (no warranty and/or guaranty  )
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: worked on this project
Nice! Thanks for the link 
Marc
|
|
|
|
|
Wow, I just read through the Trivia page. Geez, what a crazy world. I can't imagine the complexity historians have to deal with.
Marc
|
|
|
|
|
In my business we never store local time - conversion to/from that is always a UI or interface concern.
|
|
|
|
|
and how do you know which one is on the szenario of the phone call to the hotline?
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
When you enter a query (we don't have telephones in this business) the data are returned in UTC but displayed in local. In the example, yes we would need to know where the ATM was located.
|
|
|
|
|
Duncan Edwards Jones wrote: In my business we never store local time - conversion to/from that is always a UI or interface concern.
Yes, storing the UTC time is definitely the starting point, and I agree, the conversion to/from is a UI concern, but for it to do it's job correctly for the requirements, it may need additional information, at least, that's my thinking.
Marc
|
|
|
|
|
That is definitely needed, yes. Most operating systems and browsers support "locale" information to allow the user interface to discover its location.
For phone apps there is the Google maps Timezone API[^] and worst case scenario you can get the client to specify the timezone.
If you need to store where the time came from then you could have a "client offset" field that tells you what time the client thought it was when they wrote the record.
|
|
|
|
|
Time is an illusion. Lunch time doubly so.
However, you always store your times in UTC. Convert to local time for the observer, on-the-fly.
If I am reading this in CA, then show that time zone (with the -PST). If I am in Washington, show -EST or -EDT)....
Or did I misunderstand the question?
|
|
|
|
|
Basildane wrote: Convert to local time for the observer, on-the-fly.
A bit difficult for the szenario of calling the hotline.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Basildane wrote: However, you always store your times in UTC. Convert to local time for the observer, on-the-fly.
Yup.
Basildane wrote: Or did I misunderstand the question?
Except the time displayed may need to be relative to where/when the transaction took place, rather than where the viewer is.
Marc
|
|
|
|
|
Marc Clifton wrote: Except the time displayed may need to be relative to where/when the transaction took place, rather than where the viewer is.
That's still ok. It's much better to have a single authoritative point of reference (UTC) and use that rather than multiple. Take for instance the blog post, that's supposed to be relative to the poster (not the viewer). Even with the time stamp in UTC, calculating the server offset from UTC and showing that to the user, in the servers timezone, is still just as easy.
UTC is your friend.
Jeremy Falcon
|
|
|
|
|
Marc Clifton wrote: not everyone knows what "UTC" is or even
That was "unbelievable tortoise crash" right?
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Who the f**k is "not everyone"? 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
The guy who knows even  
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
