How to use this Page

Because I've shown an interest in coding in the past, No Starch Press was kind enough to offer me a review copy of The Official ScratchJr Book by Marina Umaschi Bers and Mitchel Resnick. (2015)



Sadly, I don't have an iPad or Android-based tablet, so I was unable to download the ScratchJr app to test it, but judging by the book and my experience with Scratch, I'm sure it's a wonderful tool for inspiring creativity and logical thinking.

Here's what I like about The Official ScratchJr. Book:

• It targets a very young audience - ages 5 and up
• It can be useful for parents and teachers and librarians - especially those who might find coding to be intimidating
• Unlike the Hour of Code (which I love and have used as a resource for library programming), The Official ScratchJr Book focuses more on inspiring creativity than learning the nuts and bolts of logical thinking
• The above statement notwithstanding, it still can be used to learn the nuts and bolts of simple coding and logical thinking

If at first there was a great rush to teach kids to code, there is now a push in the opposite direction. Just Google "Should kids learn to code?" and you will find a wealth of opinion on either side. Personally, I liken the "argument" to car repair.  In days gone by, many people knew how to do most repairs on their automobiles.  Now, cars' systems are so intricate, that most people have trouble doing anything other than the simplest of repairs.  Most people have cars.  Should we know how to repair them?  No, I don't think so.  There will also be a need for an auto mechanic. But, knowing how to change a flat tire sure comes in handy!  If working on cars appeals to you, become a mechanic.  The same is true of coding.  Give it a try.  If your kids are looking for a follow up to the Frozen Hour of Code project, "Code with Anna and Elsa," The Official ScratchJr Book is probably a good place to start (if you have a tablet that can run the ScratchJr app).



I'm going to pass my copy along to my school district's media specialist.  The kids have Chromebooks and should be able to make good use of it.

Add a Comment

What do you expect to happen when you shut 25 teens in a room for an entire rainy Saturday? I wasn't sure when I arrived at Skokie Public Library at 9:00am on May 30 for their first ever Community Appathon, even though I'd attended several planning meetings. The event was inspired by the National Day of Civic Hacking and spurred into being by a library patron (Maker Mom Kim Moldofsky) and her teenage son. A skilled coder, he'd attended an adult-oriented hackathon and found that a 36-hour event doesn't mix well with curfew. The goal of the appathon was to gather teens interested in developing, designing, and civic service to prototype apps to meet the community's needs.

The event ran from 9:00am to (slightly after) 6:00pm. We began the day with a State of Skokie talk that addressed many of the issues highlighted at a recent series of town hall meetings, followed by a brainstorming session to develop ideas to address those issues. Highlighted issues include safety, connectivity, diversity, environmental sustainability, the difficulty in finding information about local events, the need for an image makeover, and a need to be more pedestrian friendly. The teens then broke out into teams of five to create their apps. Three library staff and Kim acted as facilitators throughout the day: keeping everyone on schedule, serving food (bagels, fruit, pizza, popcorn and cookies), and offering assistance as needed. At the end of the day, each team presented their app to the whole group. All the teens (plus a last-minute group of teen volunteers) voted on the best one.

I came in with very little knowledge of coding. I've played with programs Scratch and App Inventor and prototyping software Fluid Ui enough to be able to talk about them. The self-identified teen coders were way beyond App Inventor. A few of the teens knew less than I did, but had design or other relevant skills. Skokie Public Library's webmaster was on hand to mentor them with coding issues, and several advanced teens helped the others periodically throughout the day, as well. SPL's teen librarian introduced teens to the art of the elevator pitch to help with their final presentations. My roles were to conduct a brief presentation on team selection, assist with user testing and design questions, and find answers to the inevitable, "Do you have an extension cord?" type questions.

The turnout, 25 teens, made the event a success. Coverage in the local paper may have boosted participation. Promotion at the local schools and word of mouth most definitely did. We were also able to entice them by offering a treasure trove of donated prizes. Local restaurants like Meatheads and tech companies like GitHub and Lenovo were eager to participate. Google even donated two chromebooks. One was awarded to the MVP of the day, as chosen by the teens, and the other was put into a random drawing along with the stickers, magnets, USB extenders, and other goodies. Each team also received a set of five matching prizes, so that no one went home empty-handed.

Participants were highly engaged and seemed to enjoy themselves. They worked independently of the staff for much of the day. One group took the initiative to send some of its members out into the community to talk with nearby business owners to gauge their interest and get their feedback on their app. In the end, all five teams completed working prototypes of their apps.

A few basic supplies were necessary to keep the program running. While most teens brought their own computers, we had several on hand for those that may not have their own. All of them ended up getting used. In addition to laptops, we also made sure to have plenty of power strips and extension cords. These also all got used as the teens' laptop batteries began to fade. For brainstorming and planning we had lots of pens, post-its, poster pads and markers. Various apple and android devices were on-hand for user testing, but didn't get used.

We identified a few areas to improve for future appathons. Several groups focused on similar problems like connectivity, image and finding information about local events, while no one worked on diversity, environmental sustainability, safety or pedestrian-friendliness. To remedy this, we might have participants vote on the top issues or ideas, and then form groups based on the top 5. Since the event also ended up running over its allotted time, it might work to extend it through dinner (more pizza!) or limit presentations to just 1 or 2 minutes, then time them to make sure they don't run long.

Click here for a video summary of the Community Appathon.

Add a Comment

In my library, we’re a little obsessed with coding.  We’ve been working on a project to introduce computational thinking and free coding resources to kids called Coder Time. For over a year, we’ve been searching for ways to teach our audience some complex ideas by experimenting with apps, activities, and lesson plans to create library programs (you can learn more about it here). While these programs were always for our older kids and tweens, we’ve been amazed at our youngest participants’ enthusiasm to jump right in. As we work with this age group, we keep finding overlap between coder concepts and early literacy skills.  For example, play teaches symbolic thinking, a skill important for both reading and coding.  Narrative skills help children understand story structure, but also strengthen computational thinking.  I’ve recently started incorporating coding concepts into my preschool storytimes.  After some trial and error and a mobbed flannel board, here’s what I have in the works:

Coder Values: Collaboration, perseverance, imagination, it’s all about attitude!  My favorite book for this is Today I Will Fly! by Mo Willems.  Partner with your parachute and kids can work as a team to make Gerald, or your elephant puppet, soar.

Algorithms: An algorithm is the set of instructions you follow to complete a task.  Understanding this is the first step in writing a program.  I’m using Lois Ehlert’s Growing Vegetable Soup to introduce the seed planting activity found in Course One of Code Studio. I also adapted their “Happy Maps” activity for use with a magnetic whiteboard. In a very simple maze of boxes, we help Bingo find his bone.  Apps like Kodable and Lightbot Jr. are too advanced for my preschool audience, so this lets me control the level of difficulty, and give the kids a more tactile experience.

Conditionals: Conditionals are pieces of code that only run when certain conditions are met.  They are the If/Then parts of coding.  A good introduction is If You Give a Mouse a Cookie by Laura Numeroff.  In looking for other ways to teach this, I found Linda Liukas’s Hello Ruby’s paper dolls. This inspired me adapt our “Teddy Wears a Red Shirt” flannel board. Teddy’s wardrobe has grown to include pajamas, yellow boots and a bathing suit.  If it’s raining, Teddy wears his rain boots all day long.

Throughout this process, our approach has always been to give families a taste of the possibilities that are out there, and help them discover that coding can be fun and accessible regardless of your background. As a result, a lot of these are variations on program staples.  If you have ideas for other ways of integrating coding into programming for preschoolers, please share!

---

Brooke Sheets is Children’s Librarian at Los Angeles Public Library’s Children’s Literature Department and is writing this post for the Early Childhood Programs and Services Committee. 

The post Coding Concepts for Preschoolers appeared first on ALSC Blog.

Add a Comment

Introduction, by R. Michael Alvarez

Today’s data scientist must know how to write good code. Regardless of whether they are working with a commercial off-the-shelf statistical software package, R, python, or perl, all require the use of good coding practices. Large and complex datasets need lots of manipulation to wrangle them into shape for analytics, statistical estimation often is complex, and presentation of complicated results sometimes requires writing lots of code. To make sure that code is understandable to the author and others, good coding practices are essential.

Many who teach methodology, statistics, and data science, are increasingly teaching their students how to write good computer code. As a practical matter, if a professor requires that students turn in their code for a problem set, that code needs to be well-crafted to be legible to the instructor. But as increasing numbers of our students are writing and distributing their code and software tools to the public, professionally we need to do more to train students how to write good code. Finally, good code is critical for research replication and transparency — if you can’t understand someone’s code, it might be difficult or impossible to be able to reproduce their analysis.

When I first started teaching methods to graduate students, there was little in the methodological literature that I found useful for teaching graduate students good coding practices. But in 1995, my colleague Jonathan Nagler wrote out some great guidance on good methodological practices, in particular guidelines for good coding style. His piece is available online (“Coding Style and Good Computing Practices”), and his advice from 1995 is as relevant today as it was then. I use Jonathan’s guidelines in my graduate teaching.

Over the past few years, as Political Analysis has focused resources on research replication and transparency, it’s become clear that we need to develop better guidance for researchers and authors regarding how to write good code. One of the biggest issues that we run into when we review replication materials that are submitted to the journal is poor documentation and unclear code; and if we can’t figure out how the code works, I’m sure that our readers will have the same problem.

We’ve been thinking of developing some guidelines for documentation of replication materials, and standards for coding practices. As part of that research, I asked Jonathan if he would write an update of his 1995 essay, and for him to reflect some on how things might have evolved in terms of good computing practices since 1995. His thoughts are below, and I encourage readers to also read Jonathan’s original 1995 essay.

*     *     *     *     *

Coding style and good computing practices: it is easy to get the style right, harder to get good practice, by Jonathan Nagler, NYU

Many years ago I was prompted to write Coding Style and Good Computing Practices, an article laying out guidelines for coding style for political scientists. The article was reprinted in a symposium on replication in PS (September 1995, Vol. 28, No. 3, 488-492). According to Google Scholar, it has rarely been cited, but I’m convinced it has been read quite often because I’ve seem some idiosyncratic suggestions made in it in the code of other political scientists. Though re-reading the article I am reminded how many people have not read it, or just ignored it.

Here is a list of basic points reproduced from that article:

• Labbooks: essential.
• Command files: they should be kept.
• Data-manipulation vs. data-analysis: these should be in distinct files.
• Keep tasks compartmentalized (‘modularity’).
• Know what the code is supposed to do before you start.
• Don’t be too clever.
• Variable names should mean something.
• Use parentheses and white-space to make code readable.
• Documentation: all code should include comments meaningful to others.

And I concluded with a list of rules:

• Maintain a labbook from the beginning of a project to the end.
• Code each variable so that it corresponds as closely as possible to a verbal description of the substantive hypothesis the variable will be used to test.
• Errors in code should be corrected where they occur and the code re-run.
• Separate tasks related to data-manipulation vs data-analysis into separate files.
• Each program should perform only one task.
• Do not try to be as clever as possible when coding. Try to write code that is as simple as possible.
• Each section of a program should perform only one task.
• Use a consistent style regarding lower and upper case letters.
• Use variable names that have substantive meaning.
• Use variable names that indicate direction where possible.
• Use appropriate white-space in your programs, and do so in a consistent fashion to make them easy to read.
• Include comments before each block of code describing the purpose of the code.
• Include comments for any line of code if the meaning of the line will not be unambiguous to someone other than yourself.
• Rewrite any code that is not clear.
• Verify that missing data is handled correctly on any recode or creation of a new variable.
• After creating each new variable or recoding any variable, produce frequencies or descriptive statistics of the new variable and examine them to be sure that you achieved what you intended.
• When possible, automate things and avoid placing hard-wired values (those computed ‘by-hand’) in code.

Those are still very good rules, I would not change any of them. I would add one, and that is to put comments in any paper citing the piece of code that produced the figures or tables in the paper. In 20 years a lot of things have changed about how we do computing. It has gotten much easier to follow good computing practices. Github has made it easy to share code, maintain revision history, and publish code. And the set of people who seamlessly collaborate by sharing files over Dropbox or one of its competitors probably dwarfs the number of political scientists using Github. But to paraphrase a common computing aphorism (GIGO), sharing or publishing badly written code won’t make it easy for people to replicate or build on your work.

I was motivated to write that article because as I stated then, most political scientists aren’t trained as computer programmers. Nor were most political scientists trained to work in a laboratory. So the article covered both style of code, and computing practice to make sure that an entire research project could be reproduced by someone else. That means keeping track of where you got your data, how it was processed, etc.

Any computer code is a set of instructions that produces results when read by a machine, and we can evaluate the code based on the results it produces. But when we share code we expect it to be read by humans. Two pieces of code be functionally equivalent — they could produce identical results when read by a machine — even though one is easy to read and understand by a human; while the other is pretty much unintelligible to a human. If you expect people to use your code, you need to make the code easy to read. I try to ask every graduate student I am going to work with to read several chapters from Brian W. Kernighan and Rob Pike’s, The Practice of Programming (1999), especially the Preface, Chapters 1, 3, 5, 6, and the Epilogue.

It has turned out to be easier to write clean code than to maintain good computing practices overall that would lead to easy reproducibility of an entire research project. It is fairly easy to post a ‘replication’ dataset, and the code used to produce the figures and tables in a paper. But that doesn’t really tell someone everything they need to know to try to reproduce your work, or extend it to other data. They need to know how your data was generated. And those steps occur in the production of the replication dataset, not in the use of it.

Most research projects in political science pull in data from many sources. And many, many coding decisions are made along the way to a finished product. All of those decisions may be visible in the code; but keeping coherent lab-books is essential for sifting through all the lines of code of any large project. And ‘projects’ rarely stand-alone anymore. Work on one dataset is linked to many projects, often with over-lapping sets of co-authors.

At the beginning of a research project it’s important for everyone to agree where the code is, where the data is, and what the overall structure of the documentation is. That means decisions about whether documentation is grouped by project (which could mean by individual paper), or by dataset. And it means reaching some agreement on whether there is a master document that points to many smaller documents describing individual tasks, or whether the whole project description sits in a single document. None of this is exciting to work out, certainly not as exciting as doing the research. But it is essential. A good goal of doing all this is to make it as easy as possible to make the whole bundle of documentation and code public as soon as it is time to do so. It both saves time when it is time to release documentation, and imposes some good habits and structure along the way.

Heading image: Typing computer screen reflection by Almonroth. CC BY-SA 3.0 via Wikimedia Commons.

The post Jonathan Nagler: writing good code appeared first on OUPblog.

Add a Comment

In early December, YALSA blogger Jami Schwarzwalder wrote a great post (with many great resources) on how to participate in Hour of Code week. I want to expand on her work and talk a little more about some of my experience with code and how that may translate into teens and code.

It seems that in today’s day and age, knowing how to code can be a crucial job skill. It gives you an edge and from a personal standpoint, knowing how to code can be incredibly empowering. It’s especially important to help get females (at any age) interested in coding because as we see time and time again, the difference between males and females involved in the technology field is astonishing (just search “girls in technology infographic” and see the fascinating percentages).

I think there are many ways to go at coding for teens. If you want to encourage girls, the video from Intel, who sponsors Girls Who Code, is pretty inspiring. The website itself, provides nice photos, information on past programs, and even the ability to download their most current curriculum for you to adapt to fit your teens.

Another similar website to Girls Who Code is Made With Code (through Google). They offer many projects for all levels of coding experience. These projects are fun and also include the ability to share with the world through their favorite social media outlet.

If you have teens that don’t have as much experience with coding, I would suggest doing the hour of code at code.org. Usually the theme of these puzzles is Angry Birds, but it looks like for the holiday season, the developers have moved over to Elsa and Anna from Frozen. It’s a great way to see “the blocks of coding” which will be helpful in future coding exercises. The videos that are every five or so levels are also helpful in letting you know what the blocks do and how they all work together.

With some coding under their belt, I think MIT’s Scratch is a good place to start. While there is a version that can be download onto your computers, their web version also works quite well. If you’re unfamiliar with Scratch, I would suggest watching some of their tutorials or even checking out Super Scratch Programming Adventure by the LEAD Project. This book would be great for teens to use (lots of cool drawings and learning is done through a comic form) and just to familiar yourself with the program (if you’re interested).

What is great about Scratch is that they can make their own projects (pretty much anything they can think of) or do what’s called “remixing.” Essentially they can look at completed projects and “look under the hood.” The teens can see how people created various projects and then “remix” and revise it for themselves. It’s a great way to learn all the capabilities of Scratch and give the teens some ideas of projects of their own.

Finally, if your teens want even more, I would direct them over to CodeCademy.  Here, they can sign up for an account and tackle many different programming languages: Python, HTML/CSS, JavaScript, jQuery, PHP, or Ruby. You go through a series of lessons, all that can be self-directed by the teens themselves. CodeCademy also has some projects to help see coding in action. I’ve personally used CodeCademy to learn Python and HTML/CSS and like the website, as well as the public forums for when I get stuck on a lesson.

Best of luck and I hope some of these resources will be useful to your teens!

Add a Comment

Name: ScratchJr
Platform: iOS 7 or later/compatible with iPad
Cost: Free

OK, I know some of you are saying, “Wait, I thought this was the YALSAblog for those working with teens. What’s up with a review of an app that’s for really young kids?” It seems crazy that the YALSAblog App of the week would review something like ScratchJr, but I have to say, there’s a lot to make it worth recommending to staff working with teens and to teens themselves.

• ScratchJr is a perfect way for any adult – library staff member, parent, teacher, etc. – to start learning about why all of this talk about teaching young people how to code is important, to begin to understand what block-based coding is all about, and to be able to gain some skills so to be better prepared for STEM-based programs that might be rolled out that integrate critical thinking, problem-solving, etc. within a coding environment.
• Any library that is giving teens the chance to work with younger children on coding projects will want to know about ScratchJr. It’s a perfect app for teens to use with kids to get the younger kids started on learning how coding works and on STEM-based activities that integrate critical thinking and problem-solving. If the teens you work with are working on this kind of project, it’s also a perfect opportunity for teens to have a chance to talk and think about how to present the information to children, how to plan and implement a program of this kind, and so on. It will take a lot of critical thinking and problem-solving on a teen’s part to put together a ScratchJr program for younger children, and that’s great.

When you get started with ScratchJr you’ll need to start a new project. As with all Scratch software and apps, the new project starts with a cat as the main character of the story, or game, or activity you are going to program. And, as with all Scratch programs you can change that character and/or add more characters to the project you work on.

What ScratchJr and other programs of the same type is all about is learning how to program by creating a process that tells the cat – or other character that you use – to move in a certain way, say something, stop and pause for a period of time, and so on. The focus is on learning how the commands you put together have an impact on what’s going on on the screen.

ScratchJr doesn’t have as many commands to work with as it’s parent product Scratch, but it has plenty to get started with for those who are learning how to program in this way. Users can move characters in all directions, have the character speak, record narration, hide and show characters and more. Users can also add backgrounds and change the look of a character using some simple character editing tools.

Any adult that is wondering what this coding thing that people are talking about as a part of learning for children and teens is all about, should try out ScratchJr as a first step in their own learning. Teens working to help younger kids will do well learning ScratchJr as well. It’s worth the time to take a look and think about how ScratchJr does have an impact on the teens and the families that you work with.

Have a suggestion for App of the Week? Let us know. And find more great Apps in the YALSA Blog’s App of the Week Archive.

Add a Comment

Title: Cargo-Bot
Platforms: iOS
Cost: Free

Learning to code is a big topic of conversation these days with a lot of discussion about the importance of teaching young people coding and programming skills. Why is this such a big topic of conversation? Because when anyone learns to code/program they have the chance to spend time critically thinking, problem solving, and troubleshooting. All important skills to have in the 21st century.

Acquiring these skills is definitely a part of Cargo-Bot, an app that uses game-play to teach the ideas behind coding and programming. Playing Cargo-Bot requires programming each game in order to achieve a a particular goal. All goals require moving boxes of cargo across or down the screen. And, while the first goals are pretty simple it doesn’t take too long for the game to become more complex and require that players think about not just left, right, up, and down but the order of those moves, looping moves, and specifying when and when not to actually make a move.

You can see how it all works in the screencast below.

Cargo-Bot is a great app for teens and library staff that are interested in learning about the basic type of thinking required in order to start programming. Anyone who plays won’t end up creating an app or website, but they will end up with a good sense of computational thinking and the kinds of things required to program and instruct a computer or device how to achieve specific goals.

Have a suggestion for the YALSA App of the Week? Let us know. And check out past Apps of the Week in the Archive.

Add a Comment

Welcome to a new feature on WordPress.com News. Every couple weeks, we’ll sit down with an Automattician to help you get to know the people who work behind the scenes to build new features, keep Automattic’s wheels turning, and make WordPress.com the best it can be. Mr. Tim Moore suggested this new feature and so we thought it only fitting that he should be first. Everybody, say hey to Tim!

What’s your role at Automattic?

At Automattic, I’m a member of Team Social. We handle projects like Publicize, Post by Email, Sharing, the new WordPress.com comments UI, and Gravatar, among others.

I also do a lot of work on Automattic’s Jetpack plugin. I have a toe in each part of Jetpack; I started out doing mostly development, though now I help with support, maintenance, and any aspect of the plugin that needs work.

What sort of work have you done in the past? What did you learn from it?

For development work, I maintained virtual machines. Usually, beyond the basic web server software (LAMP or similar), I didn’t get involved in other software packages that could be run (email, for example). I used to do this, but haven’t in a long time.

In light of some of the recent privacy policy rigamarole that has been going around in the tech world, I decided to brush up on my skills to see what I could do. I ended up setting up my own email server to handle email for several of my domains that, until then, I had piped into a Google Apps account. Because they’re low volume email accounts, I don’t need Google’s vast data centers. I ended up with a functional email server and I learned that email, a thing we take for granted, is a complicated beast.

If you have an interest in how something works, take the time to learn about it. It’s going to be frustrating (My email server certainly frustrated me!), and you’ll probably feel like you’d be better off leaving it to someone else (I felt like that too).

When you’re done, you’ll have learned something new, you’ll understand a service you’ve (maybe) taken for granted in the past, and you’ll have a new appreciation for how hard folks work to make these things available.

What do you love most about working at Automattic?

I love having instant access to some of the best brilliant minds in the field. I’m an autodidact* and love to learn; there’s nothing better than being able to jump on IRC or Skype to ask a question or have a discussion about something I don’t understand and coming away having learned something new.

I also like that my commute to my office can be different each day. Not just in, “Let’s take a different route to the office today,” but in that I can stay in bed and open the laptop, I can work in my home office, I can go to the café or restaurant. My commute can be different each night, too, if I choose to work at night.

What should the people know about you, Tim?

In my spare time (hah!), I write fiction (speculative fiction or science fiction or fantasy) and read just about anything that captures my interest. I currently have a novel and several short stories in progress and I usually read about one book a week (this week I’ve knocked off Gun Machine by Warren Ellis, the B-Team by John Scalzi, and am working on the Wool Omnibus by Hugh Howey).

I’m also a family person. I like to spend as much time with my wife, Caroline (also an Automattician!), and two daughters (ages four and one) as I can. One of the things I like to do with them, to relax after work, is cook dinner for the family.

*Fun fact: Leonardo da Vinci is one of the world’s best known autodidacts.

Did you know that Automattic is hiring? We want people who are willing to work hard, share their ideas, learn from their colleagues, take initiative to get things done without being told, and those who aren’t afraid to ask questions. Think you fit the bill? Work with us.

Display Comments Add a Comment

Title: Textastic
Platform: iPad
Cost:$9.99

Textastic is certainly not the most inexpensive app ever reviewed on the YALSA Blog, but it does something that you and your teens might be very interested in. It’s a code editing app. That means for anyone that codes web pages it’s a great resource to have in your app arsenal. (Those who do other kinds of coding can also use the app. Javascript or Perl for example.) Teens learning to code can enhance their skills while sitting comfortably with an iPad. Teens who know how to code can update web pages while using an iPad.

At the base-level Textastic works well as a tool for writing HTML and CSS files from scratch. Click on the + in the bottom menu, name the file, and get started writing the code. Those who are coders will appreciate that the coding screen includes line-numbering, as well as a row of character keys that make it easy to enter code on the iPad screen.

What makes this app even better are the options available for getting your code from your iPad to a server or file sharing app. With Textastic it’s possible to upload files to Dropbox or an S/FTP server. That means for anyone who is coding on their iPad there is no need to email files to yourself in order to get them posted on a server. Just upload them to your FTP host and voila the pages are available for viewing on the web or editing using another device or a computer. The reverse is also true. Login to a server that’s been setup and it’s possible to retrieve files that you’ve been working on on a different device or computer. Download the files from the server and work on them on your iPad. Then upload again when you’ve done the work needed.

Along with uploading and downloading it’s possible to send files as attachments, copy the content to paste into another document, and open the code in other apps on your iPad – for example Pages, GoodReader, or Side by Side.

Learning how to code is something that teens in your community might be very interested in. Learning how to code helps teens to better understand the way the web works, what it takes to make a website that is usable, interesting, interactive, and fun. Learning how to code can help you to help teens to engage in STEM related activities. Even if you don’t know how to code, or want to learn how to code, check with your teens to see who in the community has coding skills. Perhaps they want to use Textastic. Maybe they even want to use the app to teach other teens coding skills.

Add a Comment

Have you ever asked the question, "Yes, but...what do they really mean?"

Everybody has asked that at least once, right?

But, do you find yourself asking it a lot? Wondering what the true meaning is behind any conversation? Certain there must be a hidden meaning, if only you could find it?

You might be a writer if...you think everyone speaks in code.

At first, I thought this side effect of writing stemmed from the hazardous amount of rejection we writers expose ourselves to. Example: promising rejection letters that include a phrase or two about how the writer could make the manuscript better. They are so heartening. They mean, we are sooooooo close. But then, how close? And how could I really make it better? And why, suddenly, do the well-meaning editor's words seem like a code?

And then I'm off on a tangent dissecting, resectioning, imbueing, inferring, laboring without pause to get to what the editor really meant. Because it's hidden in there somewhere. It can't possibly be on the surface for all to see.

Because what my characters say never is. How could it be. Readers would never stand for it. They don't want idle chitchat. Fillers. Uh's and um's. Beating around the bush. They want code. They want puzzles. They want to get lost in a story and have to do some deciphering. They want a little fun! So we authors stylize, hide, weigh, infer, encode. We encode! Because everyone is doing it.

I think.

Maybe. 

Oh, what do they really mean?

Add a Comment

This post is going to be random and all over the place- you have been warned.

I thought using WordPress would save me time to paint more but I have become more than a little obsessed with it.

I’ve been really busy working on a web site project for a local Parish Council as well as tweaking my web site some more (I know I should stop at some point), so I haven’t done that much painting lately.

I can’t show the Parish Council website yet because it hasn’t been officially launched yet, but I’ve really learned a lot from working on it.

I have also been learning a lot more about web content accessibility guidelines (WCAG). It is very interesting thinking about how many people may view one web page in a different way. I’ve implemented many of the techniques on this web site and the Parish Council project I’m working on.  I’ll have to write up an accessibility statement at some point I guess.

Yesterday I went to the Festival of Quilts ¹ at Birmingham International with my aunt and mum. There were loads of really beautiful arty quilts everywhere and I had a good time looking at all the buttons and beads. I might be inspired to do some more sock monkeys at some point. There was one thing in the whole place that really caught my eye- it was a Korean exhibit: Chunghie Lee: Pojagi & Beyond – My Cup Overflows, I just thought it was beautiful.

Today I mowed the lawns and saved a butterfly.

Now for tea.

Add a Comment