We want you to write more tests. Yes, you. You've already been told that tests are the safety net that protects you when you need to refactor your code, or when another developer adds features. You even know that tests can help with the design of your code.
But, although you've read the books and heard the lectures, maybe you need a little more inspiration, tips, and prodding. And you need it to be in a place where when you see it, you can't ignore it.
That's where we can help. We're the "Google Testing Grouplet," a small band of volunteers who are passionate about software testing.
We're unveiling the public release of "Testing on the Toilet": one of Google's little secrets that has helped us to inspire our developers to write well-tested code. We write flyers about everything from dependency injection to code coverage, and then regularly plaster the bathrooms all over Google with each episode, almost 500 stalls worldwide. We've received a lot of feedback about it. Some favorable ("This is great because I'm always forgetting to bring my copy of Linux Nerd 2000 to the bathroom!") and some not ("I'm trying to use the bathroom, can you folks please just LEAVE ME ALONE?"). Even the Washington Post noticed.
We've decided to share this secret weapon with the rest of the world to help spread our passion for testing, and to provide a fun and easy way for you to educate yourself and the rest of your company about these important tricks and techniques.
We'll be putting episodes on this blog on a regular basis and providing PDFs so you can print them out and put them up in your own bathrooms, hallways, kitchens, moon bases, secret underground fortresses, billionaire founders' Priuses, wherever. Send your photos and stories to TotT@google.com and let us know how Testing on the Toilet is received at your company.
And meanwhile, keep writing those tests.
66 comments:
Will you be posting the back catalog of past TotT installments?
Great idea. Thanks guys !
Uncle John's Bathroom Reader watch out! :-)
A similar thing was/is in use at a place I worked. People made an effort to stay in the toilet for a long time (doodling on their PDA) and later claimed they were reading the work notes... :)
Some of my best agile development has been done whilst 'at the porcelain hot-desk', so this is a great idea.
I'm sure it will be highly absorbent.
when i'm on the toilet, i really just want to do my business, not read about boring test advice. something more thought-provoking would be nice..
I've just installed a Wi-Fi printer in my bathroom. Can Google just print the publications directly?
My new Dihydrogen monoxide powered mini laptop has helped me tremendously when harold calls...
Now I have TotT...whoa...life is good.
Can you make it a podcast like feed so that I can download the pdfs whenever a new one is available on the iTunes store? That would be awesome!
Testing: "Bombs, away!"
*listen*
*plop!*
Success!
Sounds great to already have reading material available rather than having to print something out, get it from the printer, then carry it in
Google doing this...mmmmkay....
However, I shudder to think about the PHBs who will use this to other ends...
Saves toilet paper too!
Hm. I have to say, I think this is misguided.
I've worked for a long time in the testing/QA engineering field for software (seems like every company calls it something different, and there are different expectations of each, but that just leads to my point). My point is that QA needs to have a bright line between it and development. No doubt, developers need to be good at creating good unit testing. By the same token, good QA/Testers need to be good at development.
But the two should remain separate. Go to any mature industry's engineering department, and ask how much of the release testing is done or defined by the actual development engineers. The answer will be you'll be laughed out of the office. There's good reason for this.
This is a sign of the immaturity of the software development industry. We're getting there, though. I've worked for a couple of the truly big Seattle software interests, and they are slowly getting more mature in how they deal with QA. The key is, (for as good and happy as developers doing a good job developing unit testing for their own work): SDEs are not QAEs, and the distinction should not be blurred, if you want to maintain true quality.
and providing PDFs
How about just a printer friendly version without comments?
When I go to the john, I create the Bush cabinet, I don't worry about anything more than watching Cheney and Rice being flushed to a place they belong.
I think you may be missing a certain level of irony in your "positive comments"...
You may also be missing a certain level of fibre from your diet if you are regularly on the loo long enough to read through so much...
A picture of those bathrooms would be very informative and entertaining. Please...
Simply great!! :-)
A related curiosity: a friend of mine had in his bathroom some maths formulas he wasn't able to remember easily :-)
i guess this gives a whole new meaning to a "Googlebomb".
These folks obviously need to eat more fiber.
Holy shit !!!
To respond to Joe #302
You're wrong. I'm a developer in a fortune 500 company and I test everything I do. By the time it goes to Alpha test, only field anomalies break my code. So to say "SDEs are not QAEs, and the distinction should not be blurred, if you want to maintain true quality." you're, well, full of crap. Your statements should be flushed.
Not everyone has poor software developers working for them. A true programmer can take the project from cradle to grave, or more aptly from napkin scribblings to deployment and not have problems.
I have 3000 sites with my software for over three years and have had 2 bugs related to errors on my part. Proper Software Engineering includes heavy testing during development.
I also know of one company that spends Billions (Microsoft) on everything you stated, and well, let their end product speak for itself. It does not support your conclusion.
I rest my case.
-T-
One word: awesome. (okay, I lied) And, thanks.
To respond to Joe #302
I think that you may want to rethink your position and help usher your company into quicker development. Everyone in your company should be involved in QA activities because it is everyone's job. If the developers learn from their own mistakes, then they should be constantly improving and not have to bother you with errors that could be fixed by them. The QAE should be worrying more about integration testing rather than unit testing, but the SDE should also ensure that their code is scalable and will not cause errors due to an inability to forsee problems.
ewwwwwww. possible marketing backfire? "google" & "crap"...
I have a simple question as a former-programmer, now business guy, between dev and QA.
Why not put pay performance targets on both sides as incentives per testing release?
In other words, each QA person gets $10 for each bug they find (up to 10, or whatever). Each development person gets $10 for the number of bugs not found under a certain target (10, or whatever).
Seems like an easy way to get people more motivated about the whole testing process.
To respond to Major Tom:
I commend you on having only 2 bugs in your portion of code with a 3000 site deployment. However, I'm wondering if you're an anomaly and am concerned that this methodology sets a dangerous precedent. Considering the approach of a development engineer should be, and in the best companies is, fundamentally different from that of a test engineer. The DE is solving a positive functional problem, while the TE is addressing the validation and exceptions associated with the DE's solution. When presented with requirements from (in most cases) Marketing PMs, the DE considers how to make the feature/product work, while the TE considers where and how the feature/product will be deployed (functionality and performance testing) and under what circumstances it might break (stress, robustness, and negative testing). As much as we try in our smaller organization to unite the DE and TE mindset to save headcount and to arguably improve unit testing prior to the hand-off to TEs, they will always remain firmly divided.
Its a great idea ... Well as long as I am not asked to do 'pairing' inside the toilet.
I had very good success writing my own tests as I was writing libdomainkeys. As I wrote the code, I would create the test. Every branch was labelled with a comment naming the test which forced that branch to be executed. Too bad our text editors don't (usually) support hot-linking between source files.
Gives a new meaning to "toilet training" !
Thank you for your sane and sensible comments Major Tom.
Michael said...
I have a simple question as a former-programmer, now business guy, between dev and QA.
Why not put pay performance targets on both sides as incentives per testing release?
In other words, each QA person gets $10 for each bug they find (up to 10, or whatever). Each development person gets $10 for the number of bugs not found under a certain target (10, or whatever).
Seems like an easy way to get people more motivated about the whole testing process.
This sounds like a well intentioned idea, but it leads inevitably toward disastrous consequences.
And here I've always thought of testing as a crappy, #2 priority. Thanks for throwing another log on the fire & helping me see the light!
-Ken
Just reading material? You can do better.
(From eXtreme Feedback)
Re: SDE's are not QAE's.
I think a point to be made here is that engineers of any sort tend to get accustomed to an idea or algorithm or whatever they've been working on. They see it as working just fine. The QA people are there to ensure that your idea of fine agrees with everyone elses. Sure, maybe it doesn't have bugs, but maybe the interface isn't as intuitive as it might be, or whatever. The point is, the more people that look at it before production, the more likely it is to be useful and useable. If you want to streamline your development timeline, you include QA people in the development cycle, to add their input as the project progresses. That way problems can be identified and resolved before it becomes a major problem. But you already knew that - it's your basic concurrent engineering model you learned about in college. I hope.
I actually googled for "Linux Nerd 2000" to see if I was missing out on some cool new magazine. Heh.
Before anyone of you reaches for the toilet roll,make certain that you've read the fine print first!
Michelle from Google suggested to share the following with you all:
Kudos to the effort of brainstorming the idea of testing bumper(Harry Robinson style) stickers and tests in toilets.
Here are my 2 cents:
Toilet stickers:
1. The better you code, the lesser it stinks.
2. You expect the toilet to be clean, as we expect your code to be.
3. You mess, we spot, you clean.
4. You dropped the paper roll by mistake. Fix it !
5. Thanks for remembering that you need to go back and fix the bug I found.
6. for ($i=0,$i< ($i--1);++$i) - I am not reminding your coding error :)
7. 234/8 - No! It's a cricket match score and not 234 bugs per 8 KLOC.
8. I am your friend but unfortunately our customers aren't.
9. The more time you spend here, the less time you distract me and the more bugs I find.
10. Did you come here running to think about the explanation you want to offer on why you missed that bug?
11. Don't believe me when I say; your code is working fine so far. I just want to give you a bigger surprise.
12. I heard you say, "Please leave me alone" and that is why I am not reminding you of the bug that took the longest time for you to fix it.
Tests:
1. An end user thought of running our program with a platform we no longer support. Should he get an error message - "You are not supposed to that" ?
2. "Arggh! The page is corrupted." - Does this mean you were unable to handle an exception?
3. I am going on a 3 week vacation and while I come back, I will have a report that my script generated on the reliability test. Are you sure, I wont see anything in RED?
4. "Sorry, no donut for you" - Who got the donut then?
5. The voice kept breaking, when I was using a dial up connection. Did ._ _ _ know?
6. I hear too many click sounds when I login. Do I have an option to hear less clicks?
7. I refer to James Bach's 36 heuristics to test. Do you use them to code?
8. When firewall is ON, your code isn't.
9. Proxies do not by pass bugs.
10. I tried closing the window in between. It goes away smoothy without the error message you expected to see.
11. I am always amazed at your coding skills but not the way you build your code.
12. His code never merges with anyone. Beware if you are merging with him.
13. I found a bug with your unit test script and hence I know what to test.
14. Last time my developer forgot to enable the logger. He spent a week convincing me to reproduce the issue.
15. Psst! Don't tell this to anyone. I look at our competitor product known issues and test them on our product. This helped me catch bugs faster :)
aa guys nice idea, when is the release...
debugging code sucks; testing rocks; debugging test code really, really sucks
Michael said...
I have a simple question as a former-programmer, now business guy, between dev and QA.
Why not put pay performance targets on both sides as incentives per testing release?
In other words, each QA person gets $10 for each bug they find (up to 10, or whatever). Each development person gets $10 for the number of bugs not found under a certain target (10, or whatever).
Seems like an easy way to get people more motivated about the whole testing process.
This is a horrible idea.
I will not improve quality. It will not improve relations between business, developers, and testers. In fact, it will make relations worse within the company and can lead to real bug escapes that impact customers.
This will only lead to finger pointing and time wasted chasing unimportant and duplicate "bugs".
As a tester, I have often had to make the decision about reporting a bug as one or 100,000. I don't know if the 100,000 errors my automated test found are due to 100,000 different problems in the code or just one. I could report them separately, or I could report them in groups, or I could pick up the phone and talk to a developer than could help me determine how the bug should be reported.
And what if the bug exists because a QA person did a poor job of reviewing the requirements? I could easily provide input to requirements that I know will lead to bugs just to get a bonus.
Not all bugs are due to a developer making a mistake in their piece of code. Some are due to bad requirements given to the developer. Some are due to bugs someone else created. If one developer's code does not properly interact with another developer's code, who is to blame? If the issue to bad documentation and requirements, do we blame QA?
And then we could argue about what is and what is not a bug.
There was a Dilbert cartoon many years ago about the idea of rewards for fixing bugs: Now, I'm going to code me a new minivan.
I like the idea...some of the best ideas come to me when I'm in the "john" ^^ lol
That is a great idea, I will talk my boss into it, a "SEO Testing Practices Program in the Toilet", amazing, thanks.
Great idea to share the testing experiences from Google with the whole world!
However you promised to post TotT's "on a regular basis". The last TotT episode was published over a month ago. So what's this regular basis?
I also had a question about the regularity of this. I think its a great idea, but I've had a hard time finding the collection of these. Is there a place for people to submit these, because I could come up with a few episodes.
I like the idea. I will definetely try it out.
Regards,
Komail Noori
Web Site Design - SEO Expert
Excelente aporte a toda la comunidad de testers en todo el mundo; nos dá una visión más cercana del entorno laboral y relacional dentro de Google. Gracias y saludos!!
網頁設計,情趣用品店,情趣用品專賣網
A片,色情A片,免費A片,成人影片,色情影片,a片免費看,情色貼圖,情色文學,情色小說,色情小說
AV,AV女優
辣妹視訊,美女視訊,視訊交友網,視訊聊天室,視訊交友,視訊美女,免費視訊,免費視訊聊天,視訊交友90739,免費視訊聊天室,成人聊天室,視訊聊天,視訊交友aooyy
哈啦聊天室,辣妺視訊,A片,色情A片,視訊,080視訊聊天室,視訊美女34c,視訊情人高雄網,視訊交友高雄網,0204貼圖區,sex520免費影片,情色貼圖,視訊ukiss
網頁設計,網站設計,搬家,除蟲,蟑螂,白蟻,眼科,橡膠,轉學考
^^ nice blog!! ^@^
徵信, 徵信網, 徵信社, 徵信社, 感情挽回, 婚姻挽回, 挽回婚姻, 挽回感情, 徵信, 徵信社, 徵信, 徵信, 捉姦, 徵信公司, 通姦, 通姦罪, 抓姦, 抓猴, 捉猴, 捉姦, 監聽, 調查跟蹤, 反跟蹤, 外遇問題, 徵信, 捉姦, 女人徵信, 女子徵信, 外遇問題, 女子徵信, 外遇, 徵信公司, 徵信網, 外遇蒐證, 抓姦, 抓猴, 捉猴, 調查跟蹤, 反跟蹤, 感情挽回, 挽回感情, 婚姻挽回, 挽回婚姻, 外遇沖開, 抓姦, 女子徵信, 外遇蒐證, 外遇, 通姦, 通姦罪, 贍養費, 徵信, 徵信社, 抓姦, 徵信, 徵信公司, 徵信社, 徵信公司, 徵信社, 徵信公司, 女人徵信,
徵信, 徵信網, 徵信社, 徵信網, 外遇, 徵信, 徵信社, 抓姦, 徵信, 女人徵信, 徵信社, 女人徵信社, 外遇, 抓姦, 徵信公司, 徵信社, 徵信社, 徵信社, 徵信社, 徵信社, 女人徵信社, 徵信社, 徵信, 徵信社, 徵信, 女子徵信社, 女子徵信社, 女子徵信社, 女子徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信社,
徵信, 徵信社,徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 外遇, 抓姦, 離婚, 外遇,離婚,
徵信社,徵信, 徵信社, 徵信, 徵信社, 徵信,徵信社, 徵信社, 徵信, 外遇, 抓姦, 徵信, 徵信社, 徵信, 徵信社, 徵信, 徵信社, 徵信社, 徵信社, 徵信社,徵信,徵信, 徵信, 外遇, 抓姦
買煙火,製造浪漫煙火小舖,101煙火,煙火小舖,煙火,仙女棒,沖天炮,勝利之花,甩炮,升空煙火,情趣用品,情趣,衣蝶情趣精品百貨,情趣用品衣蝶
情趣,自慰套,飛機杯,充氣娃娃,AV女優,AV,電動按摩棒,按摩棒,G點,調情棒,後庭拉珠棒,跳蛋,變頻跳蛋,有線跳蛋,無線跳蛋,潤滑液,男女穿戴用品,穿戴用品,情趣內衣,性感內衣,情趣跳蛋,角色扮演,情趣角色扮演,丁字褲,情趣內褲,性感內褲,性感吊帶襪,網襪,性感網襪,T字褲,煙火批發,情趣禮品,情趣用品
花蓮旅遊,花蓮租車,花東旅遊,花蓮租車,花蓮租車,花蓮旅遊,租車公司,花蓮旅行社,花蓮旅遊景點,花蓮旅遊行程,花蓮旅遊地圖,花蓮一日遊,花蓮租車,花蓮租車旅遊網,花蓮租車,花蓮租車,花蓮租車,花東旅遊景點,租車,花蓮旅遊,花東旅遊行程,花東旅遊地圖,花蓮租車公司,花蓮租車,花蓮旅遊租車,花蓮租車,花蓮旅遊,花蓮賞鯨,花蓮旅遊,花蓮旅遊,租車,花蓮租車,花蓮租車 ,花蓮 租車,花蓮,花蓮旅遊網,花蓮租車網,花蓮,租車,花東 旅遊,花蓮 租車,花蓮,旅遊,租車公司,花蓮,花蓮旅遊,花東旅遊,花蓮地圖,包車,花蓮,旅遊租車,花蓮 租車,租車,花蓮租車資訊網,花蓮 旅遊,租車,花東,花東地圖,租車公司,租車網,花蓮租車旅遊,租車,花蓮,賞鯨,花蓮旅遊租車,花東旅遊,租車網,花蓮海洋公園,租車 ,花蓮 租車,花蓮,花蓮旅遊,花蓮租車公司,租車花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮旅行社,花東旅遊,花蓮包車,租車,花蓮旅遊,花蓮租車,花蓮一日遊,租車服務,花蓮租車公司,花蓮包車,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮租車,租車網,花蓮租車公司,花蓮旅遊,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮租車公司,花蓮一日遊,租車花蓮,租車服務,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮旅遊,花蓮賞鯨,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,租車花蓮,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,租車花蓮,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,花蓮旅遊,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮包車,花蓮租車網,租車公司,花蓮租車,花蓮租車公司,花蓮一日遊,花蓮旅遊,花蓮旅遊租車,花蓮租車網,花蓮租車,花蓮一日遊,租車花蓮,花蓮租車,花蓮旅遊租車,花蓮租車,花蓮租車旅遊,花蓮租車,花蓮旅遊,花蓮旅遊,花蓮包車,花蓮溯溪,花蓮泛舟,花蓮溯溪旅遊網,花蓮旅遊,花蓮民宿,花蓮入口網,花蓮民宿黃頁,花蓮旅遊,花蓮租車,租車公司,花蓮旅遊租車,花蓮租車,租車,花蓮旅遊,花蓮租車,花東旅遊,花蓮賞鯨,花蓮旅遊,花蓮泛舟,花蓮賞鯨,花蓮溯溪,花蓮泛舟,花蓮泛舟,花蓮溯溪,花蓮旅遊,花蓮旅遊,花蓮租車,花東旅遊,花蓮,花東,花蓮旅遊,花東旅遊,花蓮租車,花蓮,花東,花蓮旅遊,花蓮租車,花東旅遊,花蓮旅遊,花蓮租車,租車,花蓮旅遊,花蓮租車,花蓮旅遊租車,花蓮旅遊,花蓮租車,花蓮,花東旅遊萬事通,花蓮旅遊,租車,花蓮旅遊,花蓮租車,花蓮,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮租車,花蓮租車,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮旅遊,花蓮租車,花蓮租車,花蓮包車,花蓮旅遊,花蓮租車,花蓮租車旅遊網,花蓮太魯閣,花蓮旅遊網,花蓮包車,花東旅遊,花蓮旅遊行程,花蓮旅遊,花蓮 租車,花蓮租車資訊網,花蓮租車旅遊,花蓮旅遊租車,租車,花蓮旅遊推薦,花蓮旅遊包車,花蓮租車,花蓮,花蓮租車,花蓮地圖,花蓮旅遊優惠,花蓮旅遊資訊網,花蓮旅遊景點,賞鯨,花蓮行程,花蓮旅遊,花蓮旅遊租車,花東旅遊景點,花東旅遊行程,花蓮旅遊blog
徵信社的服務項目,如婚前徵信、商業徵信、財產徵信等等,另外徵信社還可以代為討債,當有以上各項徵信服務的需求時,只要找有登記合格的徵信公司,與徵信公司簽訂徵信合約,就能保障自己的權益,所以徵信社仍是您遇到難題時的最好選擇,合法的徵信社,除了能提供您法律的諮詢外,還能協助釐清問題,尤其是棘手的外遇徵信,徵信社除了跟蹤外,還會協助您注意徵信過程的合法性。
OA辦公家具, 室內裝潢, 室內設計, 室內設計作品, 搬家推薦, 精緻搬家, 搬家公司, 全省搬家, 回頭車, 搬家服務, 專業搬家, 搬家, 托福, 多益, 搬家, 台北搬家, 搬家公司, 搬家網, 精緻搬家, 宜蘭飯店, 宜蘭住宿,坐月子餐, 月子餐, 留學, 留學, 搬家公司, 搬家, 台北搬家, TOEIC, 多益, 台北搬家, 搬家公司, 搬家, 托福, toefl, 全民英檢, 英檢, 搬家公司, 搬家, 台北搬家, 花蓮民宿, 民宿, 台東民宿, 團體制服, 團體服, 制服, IELTS, 雅思, 留學, 美國留學, 遊學, 室內設計, 空間設計, 會計師事務所, 會計師, 信貸, 貸款, 三信商業銀行, 影印機, 印表機, 傳真機, 事務機, toeic, 多益, 搬家公司, 搬家, 台北搬家, 桃園搬家, 虛擬主機 , 電腦維修, 室內裝修, 馬賽克, 磁磚, 瓷磚, 拋光磚, 企業外派, 企業教育訓練, 徵信社, 徵信, 喜帖, 馬克杯, 室內設計, 室內裝潢, 多益, TOEIC, 三信銀行, 貸款, 信用貸款, 公教貸款, 搬家, 包裝材料, 搬家公司, 全民英檢, 英檢, 網頁設計, 網頁設計公司, 日文補習班, 日本留學, 禮品, 贈品, 托福, 英文, 精緻搬家, 搬家公司, 專業搬家, 台北搬家, 全省搬家, 回頭車, 搬家服務, 搬家, 室內設計, 室內設計作品,
提供坐月子中心簡介、健康飲食、月子餐外送服務、養生藥膳等坐月子中心資訊。
提供婚禮部落格社群討論、新娘秘書、婚紗攝影及傳統結婚習俗等資訊。
Tutors家教網提供台北家教資訊,讓有家教需求的家長可以在本家教中心找到合適的家教老師。
使命必達徵信社提供婚前徵信、外遇抓姦、工商徵信、錄影拍照、行為蒐證等徵信服務。
築園成家為提供房屋仲介的 ,也就是房屋仲介網,除了買屋及賣屋等資訊外,還有影音看屋功能。
普普風室內設計網站提供室內裝潢、家居佈置、空間設計規劃、景觀櫥窗展場等室內設計資訊服務。
慾望城市徵信專為外遇、婚外情、劈腿、婚前徵信或離婚等問題題,提供最佳的徵信服務。
希望大家都會非常非常幸福~
「朵朵小語‧優美的眷戀在這個世界上,最重要的一件事,就是好好愛自己。好好愛自己,你的眼睛才能看見天空的美麗,耳朵才能聽見山水的清音。好好愛自己,你才能體會所有美好的東西,所有的文字與音符才能像清泉一樣注入你的心靈。好好愛自己,你才有愛人的能力,也才有讓別人愛上你的魅力。而愛自己的第一步,就是切斷讓自己覺得黏膩的過去,以無沾無滯的輕快心情,大步走向前去。愛自己的第二步,則是隨時保持孩子般的好奇,願意接受未知的指引;也隨時可以拋卻不再需要的行囊,一路雲淡風輕。親愛的,你是天地之間獨一無二的旅人,在陽光與月光的交替之中瀟灑獨行.............................................................................................................有時,你覺得痛。胃痛的時候,接受它,承認這個疼痛是你的身體的一部份,與它和平共處。心痛的時候,接受它,承認這個經驗是你的生命的一部份,與它和平共處。抗拒痛的存在,只會讓它更要證明它的存在,於是你就更痛。所以,.無論你有多麼不喜歡痛的感覺,還是要接納這個痛的事實。與你的痛站在同一邊,不逃避,不閃躲,不再與你的痛爭執,如此,你的痛才會漸漸不再胡鬧,才會乖乖平息下去。.................心願-你許下了一個心願,你閉上眼睛,在冥想之中把這個心願交託宙給宇整個讓宇宙推動它全部的力.量去執行.,你看見星球與星球的引力牽繫著彼此,你聽見虛空與虛空.唱裡著和妙美的聲音,為了你的心願,整個宇宙正在相互傳遞,然後你放下了心願,不僅是放下,最好你還把你的心願忘記,唯有如此,它才能脫離你,發展它自己,
當它在宇宙的遊歷結束之後,它自然會來到你身邊,以你曾經希望的方式回應你,許下,只是讓它發生,放下,才是讓>它實現,你的心願使你懂得不能執著的奧秘...................
謝順福blog蔣萬安 blog高以翔圖片男紀香blog守護甜心漫畫王祖賢mv迷你漢堡余筱萍的照片猴頭菇食譜東部巨型蜘蛛羅家英 only you楓之穀遊戲薛景求mv史蒂芬金黑塔郭翰陽mv無名挖挖挖王傑莫綺雯mtv大堡礁島主 clare范植偉的照片朱麗倩的近況Makiyo milkiway吴亭欣bt迷霧驚魂報稅軟體瘦大腿的方法狼愛豬影片 狼愛豬影片 山田優 real you 禹承妍照片吳淑敏寫真n95型口罩 藤原紀香尹雪姬販毒溫昇豪部落格 賈靜雯部落格禹承妍自殺電玩少女瑤瑤開球 吳威廷blog時尚服飾,服裝搭配 祕魯議員萊昂 最新發型 豬哥亮廣告哈拉论坛汽车租赁
PU超柔玉米跳蛋超柔細觸感花蝶的愛戀時尚豹紋雙跳蛋葫蘆凸粒G點凹凸愛潮G點長跳蛋舒爽長短激情七段甜蜜花紛超微米透明跳蛋插線老二閃耀光采粉紅老二葫蘆短蛋
Post a Comment