| Be Proud Of Your SIP Dialect |
[25 Mar 2008|12:52pm] |
I really related to the latest Joel On Software article, in which Joel, in great form, analyzes the utopia of all browsers and webpages conforming to the one and only HTML specification.
But what it really made me think of is the same problem we have in VoIP and unified communications. SIP has become the standard protocol for communication between clients, servers, gateways, etc. but each implements its own dialect of the SIP RFC's. Guaranteed that the Nortel Multimedia PC Client will not communicate flawlessly with the Avaya SES server, or that the Radvision tools would work out of the box on a 3COM server. Even if they all claimed full RFC3261 compliance, each has its own interpretation of the RFC, and each has compensated for RFC holes and ambiguities in different ways.
Effectively, you get different SIP dialects, just like you have different English language dialects and accents throughout the world.
Watching Boston Rob the other day on an old rerun of Survivor, proudly sporting his Red Sox cap and omitting r's like they're going out of style, I realized that there is one major difference between English dialects and SIP dialects. Bostonians are proud of their dialect. Canadians are proud of their dialect. The list goes on and on.
But you don't see big names in the VoIP industry publishing their SIP dialects. Quite the opposite, they all claim compliance and we all just silently understand that no one can truly be 100% compliant.
Rather than sweeping it under the rug, what would be really useful is if there was some documentation on the web about the specific dialects that the big VoIP products used, the way some of IE's eccentricities are documented. Your product uses a custom firewall detection protocol instead of STUN? Be proud of it - publish it! Your server only sends short form headers in its responses? Document it on the web! Now that would really help interoperability.
|
|
| 4 Ways To Review An Estimate With Limited Time And Limited Expertise |
[23 Mar 2008|11:34am] |
At last week's OSEF meeting, a scenario was described: you've planned a technically complex feature in your next release, and your senior developer has researched it and put out an estimate of 6 weeks to complete. Of course you trust your developers, but anyone can make a mistake. Without knowing anything about about the technical aspect of the new feature, and with limited time to review, how can you verify if the estimate is at all accurate?
1. Review The Work Breakdown
The most accurate type of estimate is a bottom-up estimate, so hopefully your developer broke down the feature into a list of tasks and sub-tasks. And the finer the granularity, the better. Are there any tasks that seem too high-level, like "Develop the UI" at 15 days, or "Multi-Thread Mechanism" at 10 days? At Macadamian, any sub-task estimated at 4 days or more is considered suspicious and should be cause for a bit of Q&A. What is really going to happen within that 15 day task? Couldn't it be broken down further into smaller sub-tasks? Without even understanding the technology, a granular breakdown of sub-tasks is already a good sign of a well-thought estimate.
2. Review The Top 3 Risks
Ask the estimator to list the top 3 risks of the feature. Often, we think only of the success path when estimating, overlooking everything that might go wrong. When it comes time to implement, the risks rear their ugly heads and the success path, and the accuracy of your estimate, is ancient history.
Have a look at the 3 risks. Are they clear and detailed? Are they really the top 3 risks, or can you think of other bigger risks? What is the probability of occurrence? What is the impact if they do occur?
What are the proposed mitigation strategies? Are they taken into account in the task breakdown?
3. Review The Non-Technical Tasks
When focusing on a complex technical feature, it is easy to forget about the "obvious" non-technical tasks - management tasks, coordination, unit testing, bug fixing, answering questions, integrating with other features, documentation, contacting 3rd party vendors, etc.
Is setup of a nightly build part of the estimate? What about the integration of tools like NUnit and FXCop? How about meetings that can add up to several hours per week? Time to integrate 3rd party vendor fixes? Time to merge the branched code into the main branch of source control?
They may be small in comparison to implementing a complex thread dispatcher, scheduling algorithm or power management scheme, but when you add up all these little half tasks, they can actually account for a significant chunk of the estimate.
4. Hold A Brainstorming Session
Although I typically recommend a single peer to review code as opposed to a whole group, when it comes to estimates I believe the more the merrier. Different people have different background, different roles within the company, different concerns, etc. Holding just 1 brainstorming meeting when an estimate is first drafted can bring up all kinds of new issues that no one ever thought of. In fact, I would say that including more of the team in the estimate review is the 1 major factor that has improved our estimation accuracy.
Of course, there are all kinds of processes and software out there that can improve your estimation accuracy: function points, Delphi technique, risk estimation calculators, Monte Carlo simulation, etc. As a product outsourcing company, accurate estimates are crucial to our business, and we're always looking for ways to tighten them up further. But additional processes can take big time and cost big money - not something that you can always justify for the work at hand.
The above tips are designed to give you the most benefit in a short amount of time. In fact, you could probably apply all 4 tips in 1 day, so you can get started on the actual development ASAP.
|
|
| Certified PMP, And Other Misc Titles |
[21 Mar 2008|04:42pm] |
|
After many hours of studying, yesterday I passed my 4 hour PMP exam. It was surprisingly grueling! I checked, double-checked and re-checked my answers, agonizing over trivial things like whether or not I had a reasonable distribution of A, B, C and D answers throughout this 200 multiple choice marathon.
And at the end of the 200 questions, what pops up on the screen? A survey from the testing center, asking me to fill out 10 more multiple choices before I received my grade!
In any case, in addition the whole learning management theory thing, I can now add the "PMP" title to my signature and business card.
Meanwhile at Macadamian, our titles have been adjusted a bit to better correspond to industry standards. In summary, my title was double-upgraded this week.
When we were smaller, I was actually really proud of how we were company without hierarchy, and everyone was pretty much a "software developer" and that was it. I would make fun of my girlfriend whose larger company gave everyone meaningless titles like "Senior Strategic Product Director of Business" or "Senior Marketing Development Manager, SSM". Now that we've grown, now that we've got global offices where the culture is more hierarchical, and now that we're facing a broader customer base, we've inevitably had to adjust our titles as well.
And you know what, it's ok. Everyone knows that a developer or a manager is only as good as his performance. But when you're competing in a world of Senior Strategic something-or-others where first impressions and elevator pitches count, you need to play the game.
So you can make fun of me if you want, but I'm proud to carry around my PMP title, and level that playing field just a little more against all those Senior VP of Directing Directors out there who really aren't any better than I am at managing projects and delivering successfully.
|
|
| Your Application Certified Green |
[18 Mar 2008|10:19am] |
This month Steve Ballmer kicked off his visit to CeBIT speaking about Green Computing, a hot topic for 2008. In particular, he lauded Windows Vista for being more power-efficient than older Windows versions like XP, consuming, he said, 33 times less power than XP when in idle mode.
But wait a second. Wasn't Vista criticized for being an energy hog, sucking up laptop battery life at an unrelenting pace?
More impressive to me is Intel's PowerTOP effort to take advantage of the Linux tickless kernel. The list of software that has been reworked to be power-efficient, usually by eliminating unnecessary wake-up's and polling, is growing at an impressive rate. The website even provides a list of coding techniques to make your applications greener.
In the future, whether it's on Windows or Linux, I could see service companies like Macadamian offering green IT services to certify applications as energy efficient. Just look at these forecasts from Forrester, indicating the Green IT consulting market to approach $5B over the next 5 years!
|
|
| What's Wrong With Turkey? |
[14 Mar 2008|04:53pm] |
I liked this intranet blog post from Nick Ratelle so much that I copied it verbatim. Thanks Nick! :)
You've probably thought about how dates and times could cause problems when localizing applications, but there's more than that. Check out this article explaining why testing your application in the Turkish locale can help you to find localization issues.
If you care a whit about localization or internationalization, force your code to run under the Turkish locale as soon as reasonably possible. It's a strong bellwether for your code running in most-- but by no means all-- cultures and locales.
http://www.codinghorror.com/blog/archives/001075.html
|
|
| A Patch A Day Keeps The Rework Away |
[11 Mar 2008|08:37am] |
I met with Ovidiu this week, the new developer hired in our Romanian office, to go over the material of first week training. Once you start development, I said, we have a requirement that you must submit "1 patch a day". Silence on the other end of the phone, a not uncommon response from any new team member, local or global. Ovidiu speaks English very well, but in this case it was like I was speaking a different language. "Let me explain what it's all about - you've heard of test-driven development, you've heard of pair programming. Well patch-a-day may just be an even stronger development process."
What is a Patch?
A patch is a portable file which contains new code that a developer wants to add to source control. It might be one new function. It might be a bug fix. It might be a skeleton of a new class. The rule is that it should be small and self-contained.
A developer works on this code on his local machine. When he is ready to submit the code to source control, he generates a .patch file, a text-based file that lists the lines of code that were added, deleted and modified. The patch file can be used to revert or re-apply the changes on the developer's machine. The patch file is portable because the developer can give the file to other developers on the team and they can apply the patch to their local copy of the code.
Index: comp/ajax/signup_user_prepare.php
==============================================
@@ -14,18 +14,48 @@
if (isset($_REQUEST['vl_id'])){
- $sm->assign("vl_id", $_REQUEST['vl_id']);
- $sm->assign("ta", $_REQUEST['ta']);
- //$content = $sm->fetch("signup_ajax.htm");
-
- $content = $sm->fetch("signup_ajax_player.htm");
+ $sm->assign("vl_id", $_REQUEST['vl_id']);
+ $sm->assign("ta", $_REQUEST['ta']);
+
+ $content = $sm->fetch("signup_ajax_player.htm");
Many source control systems (CVS, Subversion, etc.) have an option to generate patch files. Others can be adapted to generate these files or similar.
Why Use Patches?
Why even use patches? Why not commit the code directly to source control?
In Macadamian's process, the source control must always be 100% functional. A customer request for a working version of the code, a tester's request for a last minute bug fix, a request to release an application update could come at any moment. Team members must always have access to the latest copy of working code. Nightly automated unit tests must all pass on the integration server. If the utmost quality in the source control is not preserved, then it becomes a bottleneck.
The second reason to use patches is that they facilitate code review. The process works like this:
- Developer sends an e-mail to the project mailing list, containing:
- the patch file attached
- a brief explanation of the changes
- the name of one team member who will peer review the code
- The reviewer and and developer then discuss the code publicly on the mailing list, refining it as necessary
- Other team members, the architect, the manager, etc. are free to comment or do ad-hoc reviews on the code
- When all are in agreement, the patch is committed to source control
The patch file is easily readable by the readers of the mailing list, either in plaintext format or by using special viewers like WinMerge to do highlighting. Having the patches attached and sent out gives the team no excuses not to open up the patch and do an ad-hoc review.
Why Every Day?
Submitting a small patch every day has several advantages:
- small patches are easy to understand, so you'll increase the changes of getting a quality code review (if you dump a huge amount of code, the reviewer may miss things or worse, skip the review altogether)
- frequent patches mean that problems will be caught early, before the developer goes too far in the wrong direction. This is especially important when your team is made up of team members in different time zones.
Every Day, Are You Sure?
What if my function is not finished within a day? What if my class is not completely implemented? I can't submit a patch unless my code is pristine, right?
Yes you can, you must, and in fact, it's easy using the power of stubs and todo's.
A stub is a class or function which has little or no implementation. In order to produce a patch a day, when you start a new class, your first patch is probably going to be a stub:
class LoginDialog
{
bool validateUsername()
{
// TODO: validate the user name length, valid characters, etc.
return true;
}
bool validatePassword()
{
// TODO: validate the password in the database
return true;
}
void doLogin()
{
// TODO: 1. pop up a login dialog
// TODO: 2. get and validate the user credentials
// TODO: 3. login to system
}
string username;
string password;
}
With a stub, your first patch really just outlines the design of your class. You submit this code for review - it compiles, it will not hurt the source control, and it's small enough for the reviewer to understand easily. Maybe you need a function to get the database instance? Maybe it's a security risk to store a password variable? The reviewer is not concerned about implementation, he is concerned about reviewing the design, and catching problems early.
The next patches will replace the TODO's. Perhaps the next patch implements the login dialog:
class LoginDialog
{
bool validateUsername()
{
// TODO: validate the user name length, valid characters, etc.
return true;
}
bool validatePassword()
{
// TODO: validate the password in the database
return true;
}
void doLogin()
{
LoginDialog dlg = new LoginDialog();
dlg.ShowModal();
if( validateUsername(dlg.GetUser()) && validatePassword(dlg.GetPwd()) )
{
// TODO: login to system
}
}
string username;
string password;
}
This time, the code reviewer notices a flaw: what if username or password validation fails? Where's the error handling?
Instead of going back and implementing the error handling, another TODO can be added before committing to source control:
if( validateUsername(dlg.GetUser()) && validatePassword(dlg.GetPwd()) )
{
// TODO: login to system
}
else
{
// TODO: handle login error
}
The code still works and is error free, although right now all it does is bring up a dialog with no functionality. Perhaps the next patch implements the password validation and login. Perhaps later on, another patch will validate the username and even later on error handling is added, etc.
What Do I Implement Next?
The use of patches, stubs and TODO's means that your developers have to think ahead about what they're going to implement. Which is a good thing. Too often we focus on the details of an algorithm and start implementing full speed ahead, without knowing exactly what direction we're going in. Working with patches means getting your team to do a little self-planning. Like in chess, every team member needs to think a few moves ahead: they should always know what the next 2 patches will be.
Working with TODO's allows you to prioritize your work. Let's say you need a rough demo by Friday - instead of implementing the whole Login dialog, implement only the essential code for the demo, and leave things like validation and error handling for the next iteration. Consistently using the same keyword "TODO" means you can always search through the code and get a feeling for how much code is left to be written, what error handling and special cases are not yet handled, etc. Getting a TODO count gives your lead a good idea of how close to completing the project.
What about once I submit my patch and am waiting for review. How do I continue working on the code? The nice thing about having patches as files is that they can be created and code reviewed in parallel. In the above example, I might write a patch for validatePassword() function, and another for validateUsername() function while I am waiting for the first to be reviewed. I might submit patches for another class I'm working on besides Login.
Bottom line: the process encourages good design, planning and decomposition of tasks from everyone, not just the project leader or manager. Once team members get good at planning ahead and breaking down their work, they might have 4-5 patches being reviewed on the mailing list all at once.
Patch-a-day is not part of a waterfall or agile methodology necessarily - it is a development process that could be implemented in any methodology to:
* improve organization of development team's work
* facilitate fast, thorough and frequent code review
* encourage structured design, decomposition of classes and functions
* prioritize implementation of critical functionality
* track remaining work including error handling and special cases
For more information, drop me a line. It'll be worth your time.
|
|
| Sylar - Ultimate Villain or Master Debugger? |
[08 Mar 2008|06:49pm] |
From the same book I mentioned in my last post:
debugging can be an enjoyable activity that shares the thrill of the hunt and chase found in a good detective novel or video game. On the other hand, a protracted, unsuccessful search for a bug in your code quickly loses its charm, particularly when your boss is asking repeatedly about your (lack of) progress. Learning to debug well is essential to enjoying software development.
How true!! Of course, no developer likes to be stuck on a sustaining project forever, but a lot of developers lose morale after only a few short days of debugging. Often, the problem is not the activity of debugging itself, but the team's lack of skill in that activity. Some of the developers I know who have mastered the art of debugging really enjoy the hunt.
Speaking of hunt, I remember in Heroes Season 1 that Sylar, the meniachal villain who would eat people's brains and absorb their abilities, explained that his super power was "understanding how things work". When eating a hero's brain, he's searching for what makes it special and thus understand how to reproduce the hero's super power. To make an off-the-wall comparison, the master debuggers I know are like Sylar - they understand how the program is working very quickly and enjoy the thrill of tracking down the root cause of the bug as fast as possible. Brain eating and bloodthirst for murder aside, that's what I would like all developers on my team to be like!
And you thought this was going to be some boring post about debugging :)
|
|
| Another Book On The Black Art Of Debugging |
[06 Mar 2008|06:31pm] |
As I mentioned in a previous post, I've been looking on and off for a good book or training course on training teams to be better debuggers. There's so much out there on how to avoid bugs altogether - design planning, unit tests, code review, etc. but inevitably there will always be defects in your project, and having a trained team could mean the difference between 3 weeks and 3 months of debugging.
This book came highly recommended - WHY PROGRAMS FAIL: A Guide to Systematic Debugging. I'm reading the google preview to see if it lives up to its hype.
|
|
| There Are So Many Blogs Out There... But Who's Reading? |
[05 Mar 2008|08:34am] |
On google I search for “outsourcing software blog” and find 5 or 6 blogs on software outsourcing. But! All of them are missing one of the major indicators of a healthy blog - reader comments. There are no reader comments within the blogs – it looks like no one is reading, or at least, no one is interested enough to leave a comment.
Next, I google for “VoIP blog” – there are tons of them. I open the first 3 or 4 and again, no comments within the blog. Again it looks like the interest for these blogs is low.
I think I could pick any vertical - biotech, security, software tools, and find a plethora of related blogs, but blogs which aren't necessarily all that popular with readers.
By the way, the blogs I looked at are well written and have regular posts, so I don’t think the problem is the content. So why this lack of interest?
I'd like to hear your theories (and in the process get a few comments on my own blog :) In the meantime here are a couple theories of my own:
- When people read blogs, I think they read mostly for news and entertainment. Narrowing the focus of your blog makes it harder to post enough cutting edge news or be entertaining.
- The target audience for these blogs is unclear. Programmers would rather read Slashdot or Dr. Dobbs rather than news specifically on the domain in which they work. Managers and business leaders have little time on their hands to read blogs, and actually many of them might be busier writing their own blogs than reading others'. (kind of like how people spend more time editing their own Facebook pages than reading others')
- Possibly my google searches were off, and I missed some very popular outsourcing and VoIP blogs. If that's the case, I'd be interested to know about them and understand why they are so much more popular than their competitors.
Thinking about more carefully however, I think the real issue is that people need some sort of emotional connection to the blog they're reading. There's nothing emotional about "VoIP" or "outsourcing". But what about a blog on "developing products people will use" or "the right methodology for successful project delivery"? Who in the industry isn't passionate about that?
A blog that focuses on a common goal is going to hit home emotionally, and get people commenting and discussing. A blog that focuses on a particular vertical at best reads like a newsletter, at worst, seems not to be read at all.
|
|
| The Virtualization Explosion |
[03 Mar 2008|08:51am] |
The virtualization management market has seen extensive growth, growth that is expected to increase dramatically in 2008 and 209 when it is anticipated there will be over 4 million virtualization management customers.
This whitepaper from Nimsoft really opened my eyes to how big virtualization is getting in the industry. So many clients we meet are using VMWare or Virtual PC for their infrastructure or for their developers and testers. Remote desktop and application sharing are so commonplace now.
Luckily we've had experience working in this domain in the past. 2 examples that come to mind relate to Remote Desktop and Application Sharing in a VoIP product. Hopefully this experience will unlock doors for us in the future of this exciting domain.
|
|
| Burnout Risk |
[01 Mar 2008|10:51am] |
It was a little over a year ago that I sat at home, late at night, after having worked crazy hours day, and composed this e-mail to my girlfriend:
Hey, feeling pretty depressed right about now. Of course, it might have something to do with the fact that it's almost 2am, it's freezing in the house since I haven't re-adjusted the thermostat, and I haven't had dinner yet.
No matter how much work I put into this f***ing project, there's no way we'll meet the deadline. I've worked like crazy and no one seems to care.
But more than that, I just feel pretty lame, like I'm having a mid-mid-life crisis. Like, only a few years ago I was excited about the future and my potential to lead an interesting and meaningful life, but now I just feel like everything is at best very average, and at worst a total disaster.
I went on to say, in my signature sarcastic tone:
Maybe I should take an anti-depressant like paxil. Even the side-effects would be a plus. Erectile dysfunction means I'll never have to have kids to distract me from work, and insomnia will give me a chance to do even more overtime at night.
Like I said, I meant to send this to my girlfriend. But accidentally, I hit "Send", and sent
it to a mailing list that included my manager, the customer, and the team of 10 people I was working with.
How extremely embarrassing!! But - it was exactly the wake up call I needed, to realize how close I was to full-blown burnout.
There are so many jobs that put its employees at risk for burnout, and the technology sector is definitely one of them. But of course, it's only natural for jobs to be demanding. The trick is developing realistic expectations of yourself, learning to push back or cope, and just generally avoiding too much type-A personality behavior. It's also recognizing the signs of burnout early so you can do something about it.
One of the best articles I've found on the topic is from Rev. Dr. Rowland Croucher:
http://www.churchlink.com.au/churchlink/forum/r_croucher/stress_burnout.html on recognizing and preventing burnout in Christian pastors.
|
|
| Where Are All The Product Reviews? |
[26 Feb 2008|09:15am] |
I've been investigating support for bidirectional languages like Arabic and Hebrew for a client on embedded systems. Not only do these languages move from right-to-left, but also the letters you typed previously can change as you add new letters to your words and sentences! Needless to say, writing a layout engine from scratch is not for the faint of heart - using a commercial 3rd party seems the way to go.
The products I've found so far (all commercial) are:
1. Bitstream's Panorama Layout Engine (http://www.bitstream.com/font_rendering/products/panorama/index.html)
2. Monotype's WorldType Layout Engine (http://www.monotypeimaging.com/ProductsServices/wtle.aspx)
3. nScript (http://www.ncore.fi/products/nscriptLE)
4. Arphic Layout Engine (http://www.arphic.com.tw/usa/products/ifont/layoutengine_01.htm)
My guess is that these can all be quite costly, so a consumer review or product review online would sure help me make up my mind as far as which one to use, or whether to use any at all! But I can't find any such reviews.
In addition to my previous post about how a TripAdvisor-style repository for software outsourcers would be great, so would a repository of commercial software reviews. In the meantime I have to manually investigate these libraries further...
|
|
| Distributed Agile Development - The Interview |
[25 Feb 2008|03:22pm] |
Just throwing a one-liner to someone in your lab halfway around the world, because you're in the habit of doing this with someone in the same office. You fire them an email - “hey I need this feature". What you forget is that when you do this, the guy next door to you comes and has a 30 min discussion about the feature. If you do this to someone remotely, and they don’t pick up the phone to talk about it, it won’t come back as you expected. So you need to provoke things – "hey, let’s have a 30 minute call tomorrow morning about this new feature you want to do.
If there are 2 things our company knows about, it's distributed teams and agile processes.
Check out the full interview explaining more.
|
|
| Software Outsourcing - Consumer Reports? |
[25 Feb 2008|03:15pm] |
When I want to go on vacation, I get the low-down on hotels from www.tripadvisor.com.
When I need to choose a doctor, I get word of mouth from ratemds.com. And what about software outsourcing?
Does such a site exist? If not, it should! I can see that some outsourcing shops might object to publishing feedback (especially bad feedback) on jobs they've done. However, you would think that the good ones would be more than willing to participate and essentially be praised publicly for their great jobs, in an honest non-makertingy environment. Not to mention the benefit to the consumer of getting word of mouth on the different vendors they're considering.
|
|
| Lightweight Risk Management? |
[21 Feb 2008|09:14am] |
PMI states that the ethical way to estimate projects is to use quantitative risk analysis to determine risk reserves (scientifically calculated buffers of time or budget), and provide a range of ship dates with confidence percentage for each (ie. "80% chance we ship on July 4th, but 10% chance we ship on July 30").
I've been researching tools that allow the calculation of these reserves. So far the big names seem to be Palisade @RISK and Decisioneering Crystal Ball.
But these tools seem pretty heavy! A testimonial from the Crystal Ball site says:
"I have used Crystal Ball on very large ($12+ billion) to smaller ($10+million) projects. Because of these results, the project managers have revised their baseline estimates to more realistic numbers and secured more appropriate contingencies. Crystal Ball materially assisted in securing these benefits."
Umm, did you say $10+million is a small project? In that case, should I even bother with this tool for projects that are in the thousands, not millions?
There have got to be more lightweight risk analysis tools out there, and if there aren't, there should be. Suggestions anyone?
|
|
| Anti-Patterns - How Not To Manage |
[13 Feb 2008|05:21pm] |
John Torjo pointed this article out today: http://en.wikipedia.org/wiki/Anti-pattern
Anti-patterns are specific repeated practices that appear initially to be beneficial, but ultimately result in bad consequences that outweigh the hoped-for advantages.
I'm sure anyone reading this has lived through most of these at one point or another: Seagull Management, Absentee manager, even Cage Match Negotiator!
|
|
| Inbox Zero |
[12 Feb 2008|10:28am] |
Merlin Mann introduces the concept of Inbox Zero at Google:
"Clearly, the problem of email overload is taking a toll on all our time, productivity, and sanity, mainly because most of us lack a cohesive system for processing our messages and converting them into appropriate actions as quickly as possible."
In a similar vein, I attended a seminar by Jason Womack who introduced us to the Outlook Dashboard.
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
|
|
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
dthizy's journal
cheerful