Monday, December 30, 2013
Chromebook - Acer C720 A Month Later
Friday, December 27, 2013
Coffeshop Productivity
Saw this article on FastCompany...could not agree more. Working at a coffee shop can be a very productive experience. After you read the article, I have a few tips of my own.
http://www.fastcompany.com/3005011/why-you-should-work-coffee-shop-even-when-you-have-office
http://www.fastcompany.com/3005011/why-you-should-work-coffee-shop-even-when-you-have-office
Thursday, December 19, 2013
"Sinking" output
Bedrock is a templating language which means pretty much everything in your page is being output to the browser. Bedrock statements that are parsed and produce output, do so at the point where the tag has been placed. Makes sense...after all that's what a templating engine is supposed to do.
Hi this is <var $name> from <var $company_name>.
So when you have a page that includes statements like:
<ul>
<sqlselect "select * from customer where name like ?" --bind=$input.q>
<li><var $first_name> <var $last_name></li>
</sqlselect>
</ul>
...in the middle of your page, you might be surprised to see a lot of white space in the output.
That's because, while Bedrock interprets the tags and does not output anything as a result of non-output tags other than <var>, the Bedrock statements are on lines that include a new line and Bedrock dutifully outputs anything in your page that is not a tag.
One way to avoid this, is to avoid placing these tags on their own line. Another way of eating white space is to use the sink tag. Take this group of statements:
<null:foo $input.bar>
<if $foo --eq "bar">
<null:baz "buz">
</if>
Bedrock will interpret these tags, but your output will contain 4 new lines. Using the <sink> tag you can eat all of that white space.
<sink><null:foo $input.bar>
<if $foo --eq "bar">
<null:baz "buz">
</if></sink>
The <sink> tag can scoop up the contents of the output in a variable as well.
<sink:hello_world>Hello World!</sink>
Hi this is <var $name> from <var $company_name>.
So when you have a page that includes statements like:
<ul>
<sqlselect "select * from customer where name like ?" --bind=$input.q>
<li><var $first_name> <var $last_name></li>
</sqlselect>
</ul>
...in the middle of your page, you might be surprised to see a lot of white space in the output.
That's because, while Bedrock interprets the tags and does not output anything as a result of non-output tags other than <var>, the Bedrock statements are on lines that include a new line and Bedrock dutifully outputs anything in your page that is not a tag.
One way to avoid this, is to avoid placing these tags on their own line. Another way of eating white space is to use the sink tag. Take this group of statements:
<null:foo $input.bar>
<if $foo --eq "bar">
<null:baz "buz">
</if>
Bedrock will interpret these tags, but your output will contain 4 new lines. Using the <sink> tag you can eat all of that white space.
<sink><null:foo $input.bar>
<if $foo --eq "bar">
<null:baz "buz">
</if></sink>
The <sink> tag can scoop up the contents of the output in a variable as well.
<sink:hello_world>Hello World!</sink>
<sink> has one other magical property. It can also output the contents of the block to a handle.
<sink $fh>Hello World!</sink>
You can even nest <sink> tags.
<sink:foo>bar<sink>this is a comment</sink></sink>
Check out this link for more detail about the sink tag.
Monday, December 16, 2013
Chromebook - Acer C720 Day 20
Still loving my Chromebook! No change on my VPN woes yet, but I'm fairly confident my network ninja at corporate will figure it out. In the mean time I continue to read the Google Chromebook forums trying to learn about it and what potential issues people have. I was able to help someone who thought they had a Chromebook issue, but it was more than likely a problem with their Comcast router.
https://groups.google.com/forum/#!category-topic/chromebook-central/chromebook/KrJeHbucaMg
Most of the problems I see that people have are because they do not understand what a Chromebook is. There have been some reported hardware issues, but I suspect that those are few and far between and easy to spot and correct (send it back to Amazon if you we smart enough to order it from there!)
As mentioned in the forum link above my Linksys router DNS caching bug was vanquished by using Google's nameservers which is an option in the Chromebook's network setup.
Monday, December 9, 2013
OpenBedrock Moving to GitHub
Now that I've gotten the OpenBedrock project back in full swing, it's time to leave the stone age of CVS and enter the modern world by migrating to a more appropriate VCS. I've debated the relative merits for this move, but in the end, in order to create a more community driven project, moving the project to GitHub and using git as my VCS makes a lot of sense.
While the world probably doesn't need another web application framework, and no one but I may ever contribute to it, I've always viewed Bedrock with a bit of fondness. It was created in 1999 as a collaborative effort between myself and one other developer who initiated the concepts, to fill the gap that existed for a decent templating package.
Jay Sridhar's first effort, a C based package lacked the flexibility to rapidly change with the ideas we were generating, so Perl was adopted early in the project to make development easier and faster. I think there was some thought of using Perl only as a prototyping platform, but soon production applications were being built in Bedrock.
While the world probably doesn't need another web application framework, and no one but I may ever contribute to it, I've always viewed Bedrock with a bit of fondness. It was created in 1999 as a collaborative effort between myself and one other developer who initiated the concepts, to fill the gap that existed for a decent templating package.
Jay Sridhar's first effort, a C based package lacked the flexibility to rapidly change with the ideas we were generating, so Perl was adopted early in the project to make development easier and faster. I think there was some thought of using Perl only as a prototyping platform, but soon production applications were being built in Bedrock.
Sunday, December 8, 2013
Chromebook - Acer C720 Day 12
Looking to hold a webinar on my Chromebook. We've used AnyMeeting before to hold webinars for Treasurer's Briefcase, a Bedrock (and Perl) based website that offers small non-profits an easy way to do their record keeping . AnyMeeting had worked well last year on my Macbook. Because it used a Java plugin, it was difficult to initially setup for us as the hosts of the meeting owing to the constant Java security updates. It was equally a pain in the butt for clients to use. Since then they've ditched the Java plugin - Yay! - so I thought I'd try hosting a meeting on my C720.
Friday, December 6, 2013
Chromebook - Acer C720 Day 10
I had occasion last night to help a friend with a spreadsheet problem. My friend emailed me the spreadsheet (.xlsx) and I promptly opened it with Google Sheets on my Chromebook.
Monday, December 2, 2013
Acer C720 - Update Day 6
Work-from-home setup Acer C720, Samsung 2230 Logitech K750, Logitech Couch Mouse, Fujitsu ScanSnap si3000 |
So far using the C720 has been fantastic! I'm surprised at how little I actually need my Macbook Pro for the things I routinely do. Some additional observations:
Sunday, December 1, 2013
New Bedrock AMI Released
Want to try Bedrock quickly? Just released a new Bedrock AMI on Amazon's Cloud. Follow the link below for instructions.
http://twiki.openbedrock.net/twiki/bin/view/Bedrock/BedrockAMI
http://twiki.openbedrock.net/twiki/bin/view/Bedrock/BedrockAMI
We'll Worry About Billing Later - Technical Debt
For years I have been trying to explain this concept to people in business that seem to want results now without fully understanding the costs of now.
Apparently there is a name for it. I've sarcastically used the phrase "we'll worry about billing later", but it does have an official name - technical debt - the bias of businesses to cut corners during the development or design phase in order to release a product as quickly as possible by deferring features, spending less time on building in fault tolerance, or perhaps scalability.
Apparently there is a name for it. I've sarcastically used the phrase "we'll worry about billing later", but it does have an official name - technical debt - the bias of businesses to cut corners during the development or design phase in order to release a product as quickly as possible by deferring features, spending less time on building in fault tolerance, or perhaps scalability.
Subscribe to:
Posts (Atom)