Posts from August 2016

Friday, August 26, 2016

This guest post is a part of a short series about Tatyana Goldberg, Guy Yachdav and Christian Dallago and the journey that was inspired by their participation as Google Summer of Code mentors for the BioJS project. Check out the first and second posts in the series.

The success of our Game of Thrones project opened a lot of doors. First, we were invited to participate in the Morpheus Cup which is a prestigious university olympiad that brings together students from all over Europe to compete in digital challenges.

Our team rocked the competition winning two challenges and making it to the finalist stage in the third challenge. We were honored to represent our university and grateful for Google’s sponsorship of our team.

The students and mentors of the Game of Thrones project at the Morpheus Cup challenge in May 2016. From left to right: Georgi Anastasov, Emiliyana Kalinova, Maximilian Bandle (all students), Guy Yachdav (mentor), Christian Dallago (mentor), Tobias Piffrader, Theodor Chesleran (both students) and Tatyana Goldberg (mentor).

Another opportunity that followed was an invitation to speak at a TEDx event at TUM on July 28th, 2016. In the event, titled “The Common Extraordinary,” Guy presented our work with data mining as bioinformaticians, sharing how we’ve made the field of data science accessible to our students and how we helped popularize it through the Game of Thrones project.

More speaking engagements are already scheduled: at meetups, coffee talks and conferences where we plan to keep evangelizing data mining and tell the story of our open source adventure.

What’s next? We’re excited to continue as mentors and org admins in GSoC and to carry on teaching data science and JavaScript at the university. In between classes and our daily research work we’re now being asked by friends, family members, colleagues and even strangers whether we can help them use data mining to answer questions on subjects ranging from politics, science, sports and even their personal lives.

Just the other day we were approached with the idea of developing an app that would take in a set of personality traits, process them along with social network data and help in suggesting life decisions: Should I date that person? Should I really take this job? Is Baltimore the city for me?

That interest goes even beyond our personal circles. A recent trade media report pointed out that by using machine learning in an unexpected context, the Game of Thrones project demonstrated the disruptive force of data mining. This force, the article continues, could make an impact on the next industrial revolution - Industry 4.0 - where data plays a key role.

Do you have interesting questions you’d like to answer or a data set you’d like to make predictions with? Curious about BioJS or our JavaScript course? Please reach out to us on Twitter or in the comments.

In the near future we dream of starting our own consultancy, as we already have requests from companies that want our help with upcoming data science projects. It seems our team has found its entrepreneurial bent!

We hope enjoyed this trilogy of blog posts, that our story has inspired you and that you too will continue to adventure in open source and collaborative development. If you’re not involved with Google Summer of Code, consider joining. It’s a great way to build up your project and share it with the world. More importantly, it lets you work with amazing people with whom, as we learned, it is possible to reach the sky.

Monday, August 22, 2016

Google Code-in is our annual contest that gives students age 13 to 17 experience in computer science through contributions to open source projects. This blog post is the third installment in our series reflecting on the experiences of Google Code-in 2015 grand prize winners. Be sure to check out the first and second posts in the series, too.

In this post we look at the stories of three more Google Code-in (GCI) grand prize winners. Our grand prize winners come from a pool of 980 studentsfrom 65 countries who, all told, completed 4,776 tasks for 14 open source projects.

We were lucky enough to host many of these extraordinary young coders at Google HQ for a few days this summer. Over that time, we learned more about where they came from, what they gained by participating in GCI and what they plan to do as new members of the open source community.

Google Code-in 2015 Grand Prize Winners explore the SF Bay Area in this immersive Google Street View display with fellow open source program managers Stephanie Taylor and Cat Allman who run GCI.

Our first story today is that of Břetislav Hájek from the Czech Republic, who chose to work with the OpenMRS project because he sees their work as important. OpenMRS is an open source medical record system that improves healthcare delivery in resource-constrained regions.

Břetislav got into computer science through web development, so he started by working on tasks related to HTML and CSS. This gave him confidence to take on more challenging tasks. His favorite task was creating a web application for searching through patients. While he didn’t find it hard, he learned a lot and was proud to have made something useful. Reflecting on Google Code-in, Břetislav said: “That's the thing I like about GCI. I always treat tasks as opportunities to learn something new. And the learning is more entertaining since I work on real problems.”

IRC communication proved to be an important part of Břetislav’s success. Other students were there and tried to help each other out as best they could, and there were always mentors available to help guide them. He enjoyed the friendly environment. The community motivated him to work harder and try new things. In the end, Břetislav was glad to have participated and is motivated to continue his work.

Next we have Vicente Bermudez from Uruguay who discovered Google Code-in through a story in the local news celebrating a Uruguayan grand prize winner from a previous year. Like Břetislav, Vicente chose to work on the OpenMRS project because the cause spoke to him.

He got into programming through his love of video games and his desire to create his own. He hadn’t heard about programming before but initial research piqued his interest. Following his curiosity, he learned Java and expanded his knowledge from there. Conveniently, much of OpenMRS is built with Java!

The task-based structure worked well for Vicente. He was unsure of some tasks, recognizing that he didn’t know much about what they required. For instance, he hesitated to take on one that involved creating a Windows Phone app because he had never created a mobile app. But he persisted and, five days later, he had completed it and learned a lot about mobile development.

It surprised Vicente how much he learned in such a short time span. He had this to say: “During the contest I gained knowledge in a variety of fields such as programming, testing, video editing, and graphic design. The mentors encouraged us to think about quality instead of quantity, and I learned a lot from that.”

The last student story we’ll share today is that of Anesu Mafuvadze, a student from the US who worked with the Sustainable Computing Research Group (SCoRe). His introduction to computer science came through robotics in one of his high school classes which used a language similar to C++.

Anesu was thrilled by the experience of bringing the robots to life with code. He described his introduction this way: “The more I programmed the more captivated I became; I loved how easily I could convert my wildest ideas into fully functioning programs; I loved the thrill of working in an environment that demands minute precision; above all, I loved creating programs that other people found useful.”

Online documentation and YouTube tutorials fueled Anesu’s education for several years as he picked up multiple languages and began participating in programming contests. But he knew something was missing, Anesu lacked real world coding experience and had never collaborated with others. As such, he didn’t pay much attention to the readability of his code, wasn’t aware of version control, didn’t write extensive tests and had never built something for the common good.

Enter Google Code-in. Working with mentors helped Anesu deliver quality and building open source software required him to learn collaboration tools and value readability. The contest also gave him an opportunity to build on skills that he hadn’t developed, such as web development. Anesu says the experience made him a better programmer and that the introduction to open source has motivated him to use his skills on projects that benefit society.

Thank you to Břetislav, Vicente and Anesu for their hard work contributing to open source projects and for sharing their stories with us. We have one more blog post coming with more student stories so stay tuned!

Friday, August 19, 2016

Science Journal is an app that turns your Android phone into a mobile science tool, allowing you to use the sensors in your phone to explore the world around you. The Making & Science team launched Science Journal a few months ago at Bay Area Maker Faire 2016 and have been excited to see different projects people have done with it all over the world!

Today we are happy to announce that we are releasing Science Journal 1.1 on the Google Play Store and also publishing the core source for the app. Open source software and hardware has been hugely beneficial to the science education ecosystem. By open sourcing, we’ll be able to improve the app faster and also to provide the community with an example of a modern Android app built with Material Design principles.

One important feature in Science Journal is the ability to connect to external devices over Bluetooth LE. We have open source firmware which runs on several Arduino microcontrollers already. In the near future, we will provide alternate ways to get your sensor data into Science Journal: stay tuned (or follow along with our commits)!

We believe that anyone can be a scientist anywhere. Science doesn’t just happen in the classroom or lab. Tools like Science Journal let you see how the world works with just your phone and now you can explore how Science Journal itself works, too. Give it a try and let us know what you think!By Justin Koh, Software Engineer

Wednesday, August 17, 2016

Today, we're announcing that the open source version of Google's Santa Tracker
has been updated with the Android and web experiences that ran in December 2015.
We extended, enhanced and upgraded our code, and you can see how we used our
developer products - including Firebase and Polymer - to build a fun,
educational and engaging experience.

To get started, you can check out the code on GitHub at google/santa-tracker-web
and google/santa-tracker-android.
Both repositories include instructions so you can build your own version.
Santa Tracker isn’t just about watching Santa’s progress as he delivers presents
on December 24. Visitors can also have fun with the winter-inspired experiences,
games and educational content by exploring Santa's Village while Santa prepares
for his big journey throughout the holidays.
Below is a summary of what we’ve released as open source.

Android app

The Santa Tracker Android app is a single APK, supporting all devices, such
as phones, tablets and TVs, running Ice Cream Sandwich (4.0) and up. The source
code for the app can be found here.

Santa’s
Village is a launcher for videos, games and the tracker that responds well
to multiple devices such as phones and tablets. There's even an alternative
launcher based on the Leanback user interface for Android TVs.

Games on Santa Tracker Android are built using many technologies such as JBox2D (gumball
game), Android view hierarchy (memory
match game) and OpenGL with special rendering engine (jetpack
game). We've also included a holiday-themed variation of Pie Noon, a fun game that works on
Android TV, your phone, and inside Google Cardboard's VR.

Android Wear

The custom watch faces on Android Wear provide a personalized touch. Having
Santa or one of his friendly elves tell the time brings a smile to all. Building custom watch
faces is a lot of fun but providing a performant, battery friendly watch
face requires certain
considerations. The watch face source code can be found here.

On the web

Santa Tracker is mobile-first: this year's experience was built for the
mobile web, including an amazing brand new, interactive - yet fully responsive,
village: with three breakpoints, touch gesture support and support for the Web
App Manifest.

To help us develop Santa at scale, we've upgraded to Polymer 1.0+. Santa Tracker's use of
Polymer demonstrates how easy it is to package code into reusable components.
Every house
in Santa's Village is a custom element, only loaded when needed, minimizing the
startup cost of Santa Tracker.

We simplified the Chromecast support this year, focusing on a great
screensaver that would countdown to the big event on December 24th - and
occasionally autoplay some of the greatvideocontent from around
Santa's Village.

We hope that this update inspires you to make your own magical experiences based
on all the interesting and exciting components that came together to make Santa
Tracker!

Friday, August 12, 2016

This guest post is a part of a short series about Guy Yachdav, Tatyana Goldberg and Christian Dallago and the journey that was inspired by their participation as Google Summer of Code mentors for the BioJS project. Don’t miss the first post in the series. Heads up, this post contains spoilers for Game of Thrones seasons 5 and 6!

We began with two dozen students who worked on expanding the BioJS visualization library. Our class became popular quickly and the number of applicants doubled each semester (nearly 180 applicants for 40 seats in the 2016 summer term).

In 2016 our team grew to include Christian Dallago, who had joined as a GSoC mentor. Together we decided to break with tradition of our course’s previous semesters. Instead of focusing on data visualization, we wanted to introduce students to data science with JavaScript. To get our students fully engaged, we decided the project would center on data from the hit TV show, Game of Thrones.

Our plan worked — the students were engaged. It was a beautiful sight to see: GitHub repos humming with activity as each dev team delved deeper into their projects. As a project manager, you know you’ve got something good when issues are being opened and closed at 4:00 AM!

The results were mind blowing. In 50 days of programming, 36 students opened over 1,200 issues and pull requests, pushed 3,300 commits, released four apps to NPM, and, of course, produced one absolutely amazing website.

The website amasses data from 2,028 characters. Our map shows 240 landmarks and the paths traveled by 28 characters. Our Twitter sentiment analysis tool analyzed over 3 million tweets. And we launched the first ever machine learning-based prediction algorithm that predicts the likelihood of dying for the 1,451 characters in the show that are still alive.

Visualization of Twitter sentiment analysis data for Jon Snow during season 5 of Game of Thrones. The X axis shows the timeline and the Y axis shows the number of positive (green) and negative (red) tweets. Each tweet is analyzed by an algorithm using a neural network to determine whether the tweet’s writer has a positive, negative or neutral attitude toward the character.

Google Analytics for the website. Left chart shows the number of visitors to the website during the first week after launch, reaching over 73K visitors on April 25th. Right chart shows the number of visitors at a given time point during the same week.

The most exciting part of the project was predicting the likelihood that any given character would die using machine learning. Machine learning algorithms find rules and patterns in the data, things that humans cannot obviously and simply detect. Once the rules and patterns are identified, we apply machine learning to make inferences or predictions from novel, previously unseen, data sets.

Warning: The next paragraphs contain spoilers for seasons 5 and 6 of Game of Thrones!

In order to predict the likelihood of a character’s death, we collected information about all of the characters that appeared in books 1 to 5 and analyzed over 30 features, including age, gender, marital status and others. Then we used a support vector machine (SVM) to statistically compare the features of characters, both dead and alive, to predict who would get the axe next. Our prediction was correct for 74% of all cases and surprised us by placing a number of characters thought to be relatively safe in grave danger.

According to our predictions, Jon Snow, who was seemingly betrayed and murdered by fellow members of the Night’s Watch at the end of season 5, had only an 11% chance of dying. Indeed, Jon has risen from the dead in the second episode of season 6! We also predicted that the rulers of Dorn (Doran and Trystane) Martell are at a high likelihood of death and, as predicted, they were taken out in the first episode of the new season.

Of course, as is always the case with predictions, there were also misses. We didn’t expect Roose Bolton to be killed off nor did we see Hodor’s departure coming.

This experience was an amazing ride for our team and it all started with Google Summer of Code! In the next post we’ll share what followed and where we see ourselves heading in the future.

Monday, August 8, 2016

Several years ago a science journalist asked me which languages could pack the most information into a 140-character Tweet. Because Twitter defines a character roughly as a single Unicode code point, this turns out to be an easy question to answer. Chinese almost certainly rates as the most “compact” language from that point of view because a single Chinese character represents a whole morpheme (in linguist terminology, a minimal unit of meaning) whereas an English letter only represents a part of a morpheme. The Chinese equivalent of I don’t eat meat, which in English takes 16 characters including spaces is 我不吃肉, which takes just four.

But this question relates to a broader question that as a linguist I have often been asked: which languages are the most “efficient” at conveying information? Or, which languages can convey the same information in the smallest amount of space? Untethered by the idiosyncrasies of Twitter, this question becomes quite difficult to answer. What do you mean by “space”? Number of characters? Number of bytes? Number of syllables? Each of these has its own problems. And perhaps more crucially, what do you mean by “information”? The Shannon notion of information does not straightforwardly apply here.

A group of us at Google set out to answer this question, or at least to provide the form that an answer would have to take. We had the resources and experience needed to annotate data in multiple languages, and we were able to divert some of those resources to this task. The results were published in a paper presented at the 2014 International Conference on Language Resources and Evaluation in Reykjavík, Iceland.

We are now releasing the data on GitHub. The data consist of 85 sentences typical of the kinds of sentences generated by Google Now, translated into eight typologically diverse languages: English, French, Italian, German, Russian, Arabic, Korean, Chinese, which include some highly inflected and uninflected languages, and various types of morphology including inflectional and agglutinative. The data were annotated by one to three annotators depending on the language, with morphological information, counts of the marked features and other information. The main data file is in HTML, color coded by language, which makes it easy to browse but also easy to extract into other formats.

Since the basic information conveyed by each sentence can be assumed to be the same across languages, the main focus of the research was on the additional information that each language marks, and cannot avoid marking. For example, the English sentence:

The verb ending -ez, in boldface above marks “addressee respect”, a bit of information that is missing from the English original. One could have used a different ending on the French verb, but then that would not avoid this bit of information—it would be choosing to mark lack of respect, or familiarity with the addressee.

In the paper we tried various ways of measuring the differing information content of the languages relative to various definitions of “space”. Considering all the factors together, we concluded that the languages that conveyed the most information in a given amount of space were highly inflected languages like Russian, with uninflected languages like Chinese actually being the “least efficient” at conveying information.

We don’t expect this to be the final answer, which is why we are releasing the data as open source in the hopes that others will find it useful and maybe can even extend it to more sentences or a wider variety of languages. Ultimately though, any answer to the question of which languages convey the most information in the smallest amount of space must seriously address what is meant by “information”, and must pay heed to the famous maxim by the Russian linguist Roman Jakobson(1959) that “languages differ essentially in what they must convey and not in what they may convey.”

Many of us have had experience working with libraries that are clearly ported from another language. I usually talk about them as Ruby with a Java accent or Python with a Perl accent. Generally they work just fine but you can run into some low level friction — sometimes things just don’t feel right. Native gems written by members of the community solve this problem. In the case of gcloud-ruby there are some really concrete examples.

First, gcloud-ruby uses syntax that is similar to other popular Ruby libraries. For example, the syntax for specifying a table schema in BigQuery (Google Cloud Platform's very large scale data warehouse) looks like this:

The two are nearly identical. That makes getting up to speed on BigQuery easier and quicker than it would be if the Ruby library didn't use patterns that are already known to the majority of Rubyists.

Another way the gcloud-ruby library meets the community where it is at is by embracing the community's fondness for doing things several different ways. In Ruby there are often several correct ways to do a given task.

The gcloud-ruby library is no exception. There are a few different ways to authenticate and create the objects you use to interact with the API. Ruby also has many common methods that have aliases. In the standard library Enumerable#map and Enumerable#collect actually run the same code path for example. In gcloud-ruby the vision API uses aliases. Google Cloud Vision provides a single endpoint: annotate. gcloud-ruby has an annotate method but also aliases this method as mark and detect if those make more sense to you (detect is the method that makes the most sense to my brain so that's the one I use). By providing a couple of different aliases it can mean the first thing you try is more likely to work. This speeds up development time and makes learning the library easier.

The last way the gcloud-ruby gem makes Rubyists feel at home is by having comprehensive tests, a common value and popular discussion topic for the Ruby community. gcloud-ruby uses minitest-spec for testing, a popular choice that most Rubyists can easily read. When I was learning the storage API I looked at the tests for storage to learn how to use the library. There is outstanding documentation as well for those who prefer learning that way but I'm so used to looking at tests that I really appreciated that gcloud-ruby has well written and easily accessible tests.

Above are three examples of how hand-coded libraries from within the community can improve the user experience when learning to use tools. Of course, doing all the development on GitHub in the open also helps. Users can easily see what bugs people have run into and what features are next up in the production queue. And if a user has a feature request (like the previously mentioned Cloud Vision support) they can create a GitHub issue.

If you’re a Rubyist, give gcloud-ruby a shot and let us know what you think!

Wednesday, August 3, 2016

This guest post is a part of a short series about Tatyana Goldberg and Guy Yachdav, instructors at Technical University of Munich, and the journey that was inspired by their participation as Google Summer of Code mentors for the BioJS project.

Hello there! We are from the BioJavaScript (BioJS) project which first joined Google Summer of Code (GSoC) in 2014. Our experience in the program set us on a grand open source adventure that we’ll be sharing with you in a series of blog posts. We hope you enjoy our story and, more importantly, hope it inspires you to pursue your own open source adventure.

Tatyana Goldberg and Guy Yachdav, GSoC mentors and open source enthusiasts. Photo taken at the MorpheusCup competition Luxembourg, May 2016.

We came together around the BioJS community, an open source project for creating beautiful and interactive open source visualizations of biological data on the web. BioJS visualizations are made up of components which have a modular design. This modular design enables several things: they can be used by non-programmers, they can be combined to make more complex visualizations, and they can be easily integrated into existing web applications. Despite being a young community, BioJS already has traction in industry and academia.

In early 2014 we decided to apply for GSoC and we were fortunate to have our application accepted on our first try. The experience was extremely positive — the five students we accepted delivered great software and they had a big impact on the BioJS community:

The number of mailing list subscribers doubled in less than a month.

All five of our accepted students from 2014 became core developers.

Students were invited to six international conferences to share their work.

Students helped organize the first BioJS conference held July 2015.

Most importantly, the students have independently designed BioJS version 2.0 which positioned BioJS as the leading open source visualization library for biological data.

You can see three examples of the work GSoC students did on BioJS below:

MSAViewer is a visualization and analysis of multiple sequence alignments and was developed by Sebastian Wilzbach. Proteome Viewer is a multilevel visualization of proteomes in the UniProt database and was developed by Jose Villaveces. Genetic Variation Viewer is visualization of the number and type of mutations at each position in a biological sequence and was developed by Saket Choudhary.

We learned a lot in the first year we participated in Google Summer of Code. Here are some of the takeaways that are especially relevant to mentors and organizations that are considering joining the program:

GSoC is a great source of dedicated and enthusiastic young developers.

Mentors need to carefully manage students, listen to them and let them lead initiatives when it makes sense.

Org admins should leverage success in GSoC beyond the program.

Orgs need to find the most motivated students and make sure their projects are feasible.

People want to share in your success, so participation in GSoC can start a positive feedback loop attracting new contributors and users.

Most importantly: the ideas behind GSoC - the love for open source and coding - are contagious and spread easily to larger audiences, especially to students and other people who work in academia. Just try it!

Our positive experience spurred us to seek out and conquer new challenges. Stay tuned for our next post where we explain how GSoC inspired us to create a popular new class and how we applied data science to Game of Thrones.

This week we profile three more grand prize winners from Google Code-in 2015. These students came from all around the world to celebrate with us in June after successfully completing 692 tasks that resulted in significant contributions to the participating open source projects.

Google Code-in 2015 Grand Prize Winners and Mentors were treated to a cruise around San Francisco Bay.

Students were paired with mentors who guided them as they learned both new technologies and how to collaborate on real-world projects. While most students had some programming experience, many were new to open source. In the end, they learned new skills, connected with open source communities and many will continue to contribute to open source projects.

We’re proud of all of the participants and grateful to the mentors who helped them. We invited the contest winners to write about their experience and many took us up on the offer. Here are their stories:

First up today is Imran Tatriev, a student from Kazakhstan who decided to work on the KDE project because loved their philosophy and had experience with C++ and Qt. He was a finalist in Google Code-in 2014 when he worked with the OpenMRS project.

Imran’s work on KDE included contributing to projects such as KDevelop, Marble and GCompris. His biggest challenge was working on the KDevelop IDE’s debugger where he was tasked with highlighting crashed threads. Highlighting the crashed thread was trivial, finding the thread that had crashed was not. It took him five days to solve that problem and he credits his mentor with helping him to work through it.

In the end, Imran learned a lot about regular expressions, the architecture of large software projects, C++ and unit testing. What did he like most about his Google Code-in experience? Imran writes: “The most valuable moments were meeting wonderful and smart people.” He plans to continue working with KDE and apply for Google Summer of Code.

Next is Caroline Gschwend, a student from the US who worked on the MetaBrainz project. Both of her parents are computer scientists and she credits them with spurring her interest.

A homeschool student with a unique approach to education, Caroline loves to learn and voraciously consumes free online resources. She had this to say: “I think that free, online learning is an amazing benefit to our society. With access to a computer and the internet, anyone, anywhere, can learn anything.”

Caroline discovered Google Code-in through her mother who had, in turn, discovered the contest through Google for Education. Caroline dug in and decided it was right up her alley. She loved that it embraced beginners with open arms and introduced new people to open source. Ultimately, she decided to work with MetaBrainz because, as a classically trained violinist, MusicBrainz piqued her interest. Their projects are primarily written in Perl and Python and, while Caroline was fluent in Java, it was too interesting to pass up.

As with most students, Caroline found collaboration to be a big part of the learning curve -- from GitHub to Git and IRC. Her mentors and other community contributors on IRC helped Caroline through the process and, looking back, she found that collaboration to be her favorite part of the whole experience. She loved that the mentors helped her to produce professional quality work rather than focusing on quantity.

Google Code-in gave Caroline a chance to learn about collaboration, Inkspace, icon design, web development and more. She has continued her work in open source and plans to apply for Google Summer of Code.

The last student we’re highlighting today is Vale Tolpegin, a student from the US who worked on the Haiku project, an open source operating system for personal computers. He also participated in Google Code-in 2014 but didn’t feel his skills were sharp enough to attack the more challenging tasks, like the ones he tackled this time around for Haiku.

Vale took on a wide range of tasks from documentation to application development, his favorite being the creation of the Haiku Hardware Repository. The repository is a Django website that lets people search and share hardware tests to determine if a given machine will work with Haiku.

He ran into a sticky issue early on, spending nearly a week finding a race condition within an application maintained by Haiku. Vale found it frustrating, but his mentors helped him see it through to the end. That wasn’t the only big challenge he ran into and, ultimately, bested: he spent another week debugging a Remote Desktop Application, software which had a very large code base.

Despite the two time consuming challenges, Vale managed to accomplish a lot more during the contest, including building a graph plotter and fixing bugs in the Haiku package manager. Vale had this to say:

“After finishing GCI, I have continued to work with Haiku and the experiences I have gained will continue to have an impact on me for years to come. Participating in GCI has truly been a life-­changing experience!”

Thank you to Imran, Caroline and Vale for their contributions to open source and for sharing their Google Code-in experiences with us. Stay tuned, we’ve got two more posts coming in this series!