Chapter 1. Introduction
With advance apologies to purists, for simplicity I refer to these different environments as “platforms.” Even though they don’t really qualify for that description, it will do.
VBA merges similar capabilities to Google Forms, Apps Script, add-on-type user interfaces, and the object model into one platform. You need some or all of the Apps Script–related components to achieve the same thing.
This chapter will describe the platforms covered in this book. Some or all of this material will be evident to those who are already familiar with them, but this foundation will inform future chapters as we contrast the different solutions available on each platform.
Because you are probably already a VBA developer, or at least have some problems currently solved by VBA that you want to move to a different platform, I’ll keep the definition of VBA fairly brief and focus on its unique attributes (both positive and negative).
VBA applications are the most common way to extend Microsoft Office applications such as Excel, PowerPoint, Word, Visio, Outlook, and Access.
You can extend VBA’s capabilities by adding references to other custom objects held in dynamic link libraries (DLLs) or type libraries created in languages other than VBA. The API for each Office application itself is via a DLL containing the code and data required to manipulate the application object model.
You can make your own classes, create custom functions that can be called from worksheets, define and declare your own events, and access events that are triggerable by built-in and custom objects.
VBA’s integration and extensibility through library references make it very powerful indeed, but they also make it fragile. Relying on the availability of myriad external shared libraries of a particular version means that transportability from one computer to another is hit and miss for substantial scripts. Furthermore, if DLL providers fail to keep their libraries current you might be unable to move to new versions of Office at will.
The development object model is accessible from VBA, which means that you can write or modify code from code. This powerful capability is one of the serious security holes that has led to VBA being both a desirable and easy target for hackers.
Microsoft’s response has been to intensify lockdown with each successive version of Office. Nowadays, by default, you can’t run macros (as VBA procedures are known) or even save a document containing VBA. Even the developers’ view and access to VBA is hidden.
Some operations can be performed asynchronously, although the capability is very limited and somewhat of a science project to implement. An asynchronous operation is one that is performed while the main execution flow continues—for example, fetching data from an external website, returning control to the main flow so that it can do something else at the same time, and receiving a callback to be handled when the fetch is finished. VBA does not have good support for asynchronicity, and most operations are processed strictly in sequence. My view is that if you are worried about asynchronicity in VBA you are probably doing it wrong, or using the wrong tool.
Efficiency and Performance
VBA compiles (automatically) into an intermediate language called P-code (pseudocode). Libraries and controls written in other languages and referenced by VBA are already compiled down to P-code, and their capabilities extend VBA efficiently.
Most applications tend to be small scale, so performance becomes an issue only where memory is scarce and large workbooks are being processed. The garbage collection algorithm in the VBA engine seems to be fairly poor, meaning that you must take care when creating large memory structures with backreferences.
Typically the code is container-bound, meaning that it forms part of the spreadsheet or document on which it is supposed to operate. When you make a copy of, for example, a macro-enabled spreadsheet, the code comes with it, which leads to code and version sprawl that’s difficult to contain. It is possible, through add-ins, to run code in one spreadsheet that resides in another, but in my view that simply makes a messy situation even worse.
The benefits of P-code (a common intermediate language for libraries) were further diluted when a different standard was introduced for the .NET Framework, complicating things even more.
To be able to support apps written in the .NET Framework, an entirely new runtime and development environment (VSTO) was introduced, again with different versions needed for different versions of Office.
What is VBA good for?
It’s clear that writing enterprise-grade, maintainable software using a container-bound platform with difficult-to-control dependencies is challenging.
VBA is great for small, often one-off, computational tasks and for organizing data extracted from other sources.
Despite its age, the integrated development environment (IDE) is a pleasure to work with, and so much has been added over the years you can do almost anything you want with VBA. It also comes with a macro recorder; you can record a series of keyboard actions, and the recorder will generate their VBA equivalent. This functionality seems to have been largely abandoned in later versions, where many actions that operate on the newer additions to the object model are not recorded.
I have mixed feelings about the macro recorder. The positive aspect is that a user can get some insight into how to manipulate the object model. On the negative side, I’ve seen many dreadful VBA applications based on macros that began life as a series of recorded macros. It’s not a good model from which to learn.
Apps Script does not have anything like this, and the type of skills needed to create enduring applications probably cannot be learned from such a tool.
Overall, VBA offers graceful automation coupled with easy implementation. It is a hard act to follow.
A Quick History
Because of the differently branded ECMAScript implementations, it’s hard to exactly pin down which features a particular implementation supports. The usual way is to refer to the ECMAScript version specification, the latest of which is version 6, with version 7 under development.
- Everything is an object, including functions.
- Variables can be “almost equal.”
- Key/value pairs and JSON are part of the language.
- Everything is case-sensitive.
- The IDE doesn’t help you as much as it should (compared to the VBA one).
- There are always many ways to do the same thing.
- I’m pretty sure you’re going to like it—maybe not at first, but soon.
It Runs on a Server
The purpose of Apps Script is to extend Google Apps. This means that it needs access to the object model for Sheets, Docs, Drive, and so on.
At the time of writing, the services in Table 1-1 are all exposed as standard Apps Script services.
|Service interface||Accesses Google service||VBA counterpart object model|
|DriveApp||Drive||Local files via Windows.Scripting|
|FormApp||Forms||Userforms via VBA in Office apps|
|Maps||Geocoding, Directions, |
and static maps
A further 18 APIs are exposed as advanced services (e.g., Analytics, BigQuery, Fusion tables, YouTube); another 14 (e.g., Cache, Properties) are available as script services.
Strangely missing from this list are Google Slides and Drawings, and although requested from time to time, scripting implementation for these doesn’t seem to have much priority with the Apps Script product team.
Fully Authenticated Environment
OAuth2 APIs are used for both authentication (i.e., that the requestor is who they say they are) and authorization (i.e., that they are allowed to perform the requested operation on the targeted resource). Google’s authentication implementation (like those of many others, such as Microsoft and PayPal) is built to the OpenID Connect specification, and its role is to validate identity. Once identity has been verified, confirmation is required to ensure that the validated identity has the authorization to access the resource requested. This combination of operation and resource is known as scope.
OAuth2 can be a fairly complex business when you’re working from a browser-based client, and generally involves the use of a helper API. In the server environment of Apps Script, authentication and scope authorization is built in and handled automatically, removing significant complexity barriers to getting started.
Because you are running in a shared server environment, Google goes to some lengths to ensure that you don’t accidentally create runaway processes, or abuse its service (which is, after all, free) by running processes for hours that really should be run on some of its other (paid) cloud offerings such as App Engine.
A process can run for a maximum of six minutes, and there are various rate and quota limits on what you can do with each service.
Rate limiting is where Google has set a ceiling on how rapidly you can repeat an operation. For example, if you create and publish an Apps Script web app, it will fail if you attempt to execute it more than 30 times a second—even if that is the only time you invoke it in a day.
Quota limiting is where a total number of operations is restricted over the duration of some time period. For example, you cannot send emails to more than 100 different recipients in the course of one day. Although there is clearly a need for such restrictions, they’ll be unfamiliar to those accustomed to VBA, and it can be very frustrating and complex to build schemes (such as sleeping between service calls or using exponential backoff for queries1) to negotiate these obstacles.
Just like Office and VBA, Apps Script is best suited to small tasks that extend docs rather than large, resource-intensive systems. It is certainly possible to create complex and sophisticated workflows on the Apps Script platform, but that is the exception.
In addition to the quotas, performance is also controlled, so as a rule of thumb, tasks will take longer on Apps Script than in VBA.
The tradeoff is cloud-based accessibility against client-based complexity.
Various performance aids, such as the caching service, are available (and don’t use up any quota), but you need to be extremely careful how you structure your app in order to minimize service calls and unnecessary repetition (all good things but less critical in VBA).
A discussion of how to implement these methods of efficiently using Apps Script services will be built into some of the examples in later chapters.
One of the killer features of Apps Script is that it enables you to schedule and run scripts without being logged on. This means you can, say, run regular reports, or summarize data every hour or at 5 a.m. These kinds of scheduled events are called time-based triggers.
There are strict quotas on the number of triggers you can have and how much daily runtime they consume, which lessens their usefulness and increases complexity, as the number of workarounds you need to build increases with the more triggers you have.
Another killer feature is the web app. You can publish a web app using the HTML service (to serve up web pages generated by your app), or Content service (to serve up data from your app).
These web apps can service both GET and POST requests by executing Apps Script functions server-side, and provide a convenient way for non–Apps Script apps to get access to docs resources, effectively turning Apps Script into a web server or RESTQuery server.
Previous versions of scripts are maintained for fallback, and there is an extensive library system that you can use to share common code between apps.
You can create both standalone scripts and container-bound scripts—the latter of which reside in a particular document, from which it’s clearly more complicated to share code. For this reason, I tend to stick to standalone scripts.
If you are writing custom scripts (i.e., a script accessible from within a formula in a spreadsheet cell), you can do so only from container-bound scripts—which could lead to the kind of code sprawl you see in VBA.
Similarly, templates intended to be used by the HTML service must also be local (although there are ways around this using libraries), which again can lead to code sprawl.
The development and debug environment for Apps Script is very poor. Autocomplete for services is implemented, and you can use JSDOC (comments in code are marked up to describe the purpose of and arguments to a function) to implement some limited autocomplete from libraries that you have written and reference from your script.
Inexplicably, though, IDE autocomplete is not implemented for functions in the current script, yet it is for custom functions accessed from a worksheet cell.
HTML service apps are especially hard to debug, because they execute dynamically generated code in the browser. Some limited interactive debugging can be done with the browser’s Developer Tools, but often the code (as you wrote it) is not visible.
Logging is also fairly limited, as you cannot see any results until the script is finished executing, but the execution transcript, which shows the call details to many Apps Script services, is a useful feature.
It is possible to develop using an add-in for Eclipse, but you have to upload the edited file to be able to run it, and it doesn’t improve the debug capabilities.
For me, the IDE is the most disappointing feature of Apps Script, and is a big step backward when you’re coming from the more integrated VBA environment.
What Is Apps Script Good For?
As with VBA, if you are writing enterprise-level scalable applications, then Apps Script is probably not the right platform. Apps Script is perfectly suited for connecting to and using other APIs, opening up great integration possibilities for building apps that take data from many places and enrich your docs experience.
The HTML service exposes Apps Script functionality, and allows for the building of much more usable (but harder to achieve) UIs than those you could create with VBA.
Apps Script is very effective for getting something running quickly, whether a production solution or a prototype of a more scalable solution. Because it is part of the Googleverse, authentication to other services is largely built in, so identity and access management are part of the fabric of the platform.
Because it is in the cloud, development across multiple devices is no longer the complexity (and license) problem that it is with VBA, and the platform is always at the most recent version. These benefits allow you to build much more collaborative workflows and manage who is running what more confidently.
Many enterprises are still concerned about the security aspect of running apps and storing their data in the cloud. In many ways, centralizing one version of a document that supports real-time collaboration, and to which access to data and scripts can be finely controlled and monitored, is an extremely secure model.
In a distributed solution using various versions of Windows and Office on files stored on PCs, laptops, and shared network drives, email is often used for collaboration outside the enterprise, leading to externally exposed documents with scripts and data at different revision levels. Having one copy of a document, and being able to control access to it from anywhere, seems a more secure paradigm—at the very least it’s cleaner from a version control and document sprawl perspective.
With the HTML service, you can create an engaging UX that’s responsive (it runs client-side) yet still has (indirect) access to the Google Apps Script services and data.
Types of Add-Ons
There are two types of add-ons:
- These run in a 300-pixel-wide frame on the right of the screen and are best for persistent data related to what’s in the main document.
- These run in a pop-up dialog box and can be used to collect (or display) one-time data from the user.
Add-ons are added to the applications menu system.
You can also create a “nonpublished” add-on from a container-bound script by adding entries to the applications menu system that execute a container-bound script upon selection. These can display sidebars and dialog boxes too.
The difference is that a real add-on can be published to the Chrome Web Store and is available for installation by any Apps user.
Nowadays, though, client code is run in an iframe environment, and the restrictive and poorly performing regime has now been removed, paving the way for more responsive add-ons.
The Publishing Process
In order to maintain quality, publishing an add-on to the Chrome Web Store requires an additional step involving a Google add-on review team. This can be a fairly laborious process, with a back-and-forth conversation in which changes requested by the review team are implemented by the developer, who subsequently resubmits the add-on for further review, ad infinitum.
As an alternative, you can publish add-ons within a domain (not public), which is subject to a less vigorous review process.
While it is important to ensure quality items are being published in the store, I believe some changes are needed to streamline the process, along with some kind of publishing option to selected people who don’t need this kind of review.
Many developers who are doing this as a hobby or learning experience (you can’t yet monetize add-ons) lose interest partway through the current process and their add-ons never see the light of day.
The balance between policing standardization and allowing fresh, innovative approaches is a difficult one.
Google Forms are a simple way to collect data in a questionnaire format. A link to a form is sent to potential respondents.
Forms are designed using an interactive tool. The main features are as follows:
Data is automatically stored in a spreadsheet.
Data validation takes place in form fields.
Routing can be controlled based on answers to specific questions.
Forms can be extended through Apps Script.
For a quick solution, using Forms avoids the complexity of creating a UI with the HTML service and Apps Script and is a good compromise for short and simple data collection work, although more complex workflows can also be handled in Forms through Apps Script and add-ons.
Add-ins can also refer to Office app extensions loaded from separate template files, or from COM or VSTO libraries and managed by the Office app’s add-in manager.
Office add-ins have nothing to do with these capabilities.
In principle, an add-in is very similar to an add-on. There are two kinds of add-in:
- The taskpane add-in, which is equivalent to the sidebar add-on
- The content add-in, equivalent to the dialog add-on
Microsoft and Google between them have created a complex soup of acronyms that’s hard to fathom. Here’s a summary:
- Microsoft Office add-ins have been around for a long time and refer to extensions than can be loaded to a document from a separate extension file.
- Google Apps add-ons are HTML applications that can communicate with server-based Apps Script, but that run in the client browser and present as either a sidebar (equivalent to the Office taskpane add-in) or as a dialog box (equivalent to the Office content add-in).
- Has a fixed repertoire of methods and properties that can be used to fetch certain data from the underlying document
- Supports some level of binding (e.g., a client event is triggered if a bound cell changes value)
The Apps Script API:
- Can launch any server-side script from the client and get back a response of your own design
- Does not have any binding, but can emulate binding by periodically calling a server-side script that monitors for changes from the client.
This means that Microsoft add-in capabilities are limited to whatever is implemented in the API, whereas Apps Script can execute any customized script.
I believe we’ll see some changes with the Office 365 unified API (currently in preview). This exposes Office 365 services via a REST API, in much the same way as Google APIs expose Google services.
This may lead to a much more open solution for Office services.
1 Exponential backoff is a technique for progressively slowing down the rate at which an operation is attempted to improve its chances of executing successfully.
Google Apps Script
Scripting platform developed by Google
- Cloud based debugger for debugging App Scripts in the web browser.
- It can be used to create simple tools for an organization's internal consumption.
- It can be used to perform simple system administration tasks.
- Community-based support model. 
- Processing limitations – As a cloud-based service, Apps Script limits the time that a user's script may run, as well as limiting access to Google services.
- Currently Google Apps Store does not allow direct connection to internal (behind-the-firewall) corporate databases, which is key to building business apps, however, via use of the JDBC service, this can be overcome, if connections are allowed from Google servers to the internal database server. Similarly, lack of other connectivity, such as LDAP connectivity, limits the level to which GAS can be used in the enterprise.
- Due to the cloud nature of Apps Script, functions related to date and time will produce results that seem to be incorrect due to the data crossing time zones. Using Date/Time objects and functions without very precise declaration and thorough testing may result in inaccurate results.
In March 2014, Google introduced add-ons for Docs and Sheets (soon followed by Forms). The add-on stores let users add extra features to Google editors, such as mail-merging, workflows, diagrams builders,... All add-ons are either 100% built with Apps Script or simply use Apps Script to display a UI in the Google editors while relying on an external backend to perform some tasks. For example, MailChimp, a mail-merging tool, has an add-on for Google Docs that communicates with MailChimp platform to send emails.
Before add-ons, it was possible to publish scripts for Google Sheets in the Script Gallery. When users installed scripts through this gallery, a copy of the Apps Script code was installed on the user's Sheet. With add-ons, the source code is not visible to the end user and everyone is using the latest version published by the developer. This new approach makes it easier to support existing code and helped convince several companies, such as MailChimp or LucidChart to invest in Apps Script.
As part of the add-ons release, Google also introduced a UI Style Guide and CSS package to help developers built add-ons that integrate smoothly into the editors. Each add-on is also reviewed by Google before its publication and developers can benefit from advice from Googlers to provide a better user experience. It is not possible to embed ads in add-ons but it is possible to monetize them.
- ^Meyer, David (August 20, 2009). "Google Apps Script gets green light". CNet. Retrieved 26 March 2011.
- ^Koleda, Eric (August 21, 2019). "Celebrating 10 years of Apps Script: looking back on how it started". Google Cloud Blog. Retrieved 22 August 2019.
- ^Rochelle, Jonathan (May 27, 2009). "Old tool, new tricks". Google Cloud Blog. Retrieved 22 August 2019.
- ^Levey, Evin (August 19, 2009). "Google Apps Script Launched to Google Apps Premier and Education". Google Apps Script. Retrieved 22 August 2019.
- ^Google Apps Script
- ^Bring a little something extra to Docs and Sheets with add-ons
- ^Google Inc. (August 28, 2018). "Built-in Google Services". Google Apps Script. Retrieved 16 May 2019.
- ^"Quotas for Google Services | Apps Script".
- ^"JDBC | Apps Script".
- ^"Issue 1035: utilities.formatdate subtracts a day". Retrieved 17 December 2012.
- ^UI Style Guide for Add-ons
- ^I've started a little experiment...
A User of Google Apps Script
I currently don't have use for this but I will soon enough which is why I've downloaded it... Looking at some other reviews I see that some are saying theres too much going on in one area, well that's probably because you're not a dev (developer) and not used to seeing great lumps of text or punctuation; like semi colons. And I've seen many saying they thought this app was for screen play, well the title doesn't suggest that at all, I must be blind if others can see it stating 'screen play', it does say "Google Apps" script, you know, scripting for Google Apps? The description can explain a lot if you read them... However, this app does have much potential, and I can see this coming of use to me very soon, so thanks for the great app "Google Apps" Scripting.
Is this review helpful?
Your review, profile name and photo will appear publicly in Google’s services. Your review must comply with the Google Workspace Marketplace Comment Guidelines and Review Policies. Learn More
A user of Google Apps Script
May 21, 2020
About all websites
A user of Google Apps Script
December 6, 2019
What programming language should I learn first? The answer to this question depends on who you ask. If you ask Ben Collins, he’ll tell you to learn Google Apps Script.
Even if you haven’t heard of Google Apps Script before, there are some compelling reasons to make it your first programming language. In today’s special guest post, Ben is here to explain why.
Take it away, Ben!
Disclosure: I’m a proud affiliate for Ben's courses. If you buy a product through my links on this page, I may get a small commission for referring you. Thanks!
Google Apps Script is a cloud-based scripting language for extending the functionality of Google Apps. It also happens to be a great first programming language to learn.
You write Apps Script in your web browser and it gets executed on Google’s servers.
I started learning Apps Script in 2014 and it’s given me a sense of accomplishment and degree of coding confidence that I never experienced with other languages.
I’ve had fun building tools that have saved me from hours and hours of tedious work. I’ve built programs for clients that connect Google Apps to third-party marketing tools. I’ve built automated dashboards that have reduced reporting workloads to almost nothing.
In this post, I’ll share seven reasons why you should consider Apps Script as your first programming language. Hopefully, you’ll be persuaded to give it a try and see for yourself how rewarding it can be.
An Apps Script tool to automatically import MailChimp campaign data into Google Sheets
#1. You start from familiar territory
If you use Gmail, Google Sheets, Docs, or other G Suite apps, then you’re already familiar with the look and feel of Google tools. Apps Script is no different and seamlessly extends the possibilities of what you can do with G Suite tools.
I found it super helpful when learning Apps Script to start with scripts attached to Google Sheets (known as container-bound in Apps Script parlance), so that I could toggle back and forth between the script editor and the Google Sheet and see the effects of my code immediately.
If you’re comfortable with formulas in Google Sheets, then you can definitely crack Apps Script. It may take a little longer than learning a new formula but stick with it and you’ll soon get the hang of it.
#2. No configuration or setup required
One of the best reasons to learn Google Apps Script as your first programming language is that it’s very, very easy to get started. There’s no risk of you getting lost in the terminal installing packages or configuring programs.
There are only three steps to get started: 1) Open your browser, 2) Create a new Apps Script project, and 3) Start coding.
Similarly, when you’re ready to run your Script, it’s very simple. You just press the Run button!
(You’ll have to authorize your script the first time you run it, or whenever you add additional services like other G Suite products. What you’re doing is setting the scope for your script, so that it only has access to what you’ve specified.)
#3. Build cool and useful tools immediately
This is my favorite reason why you should choose Google Apps Script as your first programming language.
Once you know a little bit of Apps Script, you can immediately start to build useful tools.
It’s the main reason I was able to stick with it when I hit the inevitable hurdles.
It’s really motivating to see early wins when you’re learning a new subject. Especially when you’re learning something that’s technical and potentially challenging.
With Apps Script, you have a chance to build something useful, rather than random Fizz Buzz algorithms. When you automate a tedious task or a colleague pats you on the back because your script saved her an hour a week, it’s a really good feeling.
For example, you could easily write a script to automatically import a CSV file into a Google Sheet on a daily basis, saving you the time and pain of doing it manually.
Another example, and one I use myself, is to automatically email a PDF copy of your business reporting Sheet to the relevant people on a set schedule. In my case, I get a fresh email every morning, sent by my Apps Script program, with a detailed business report with the latest data. This all happens automatically with no intervention on my part.
Start coding now
Stop waiting and start learning! Get my 10 tips on teaching yourself how to code.
Success! Now check your email to confirm your subscription.
#5. Good documentation and resources
Learning a new language is challenging. Good documentation and a helpful support group can make the difference between sticking with it and mastering the language, or giving up just when you’re on the cusp of a breakthrough.
The documentation and resources available today are excellent, much better than when I started learning Apps Script in 2014.
There are plenty of Apps Script questions on Stack Overflow and an increasing number of people creating dedicated Apps Script tutorials online.
In December 2018, I launched a free, introductory course teaching Apps Script from scratch. Over 4,000 students have since signed up and seen how easy and rewarding Apps Script can be.
#6. You learn important concepts
You can add menus to your Google Docs, Sheets, Slides or Forms, so you can execute your Apps Script code without having to open up the editor window.
For example, you might add a custom menu to execute a function that creates a PDF invoice from your Sheet and emails it directly to your client (without you having to even open Gmail).
You can also add alerts and pop-ups to create a richer experience for anyone using your script.
Custom sidebars can be used for more complex scripts that might require the user to make choices, select data, etc. You can add forms, buttons, and CSS styling to these sidebars, and all of this code lives inside your Apps Script project.
Apps Script has triggers built in so you can run your script on a particular schedule, or when a specific event happens such as a Google Form submission. For example, I have a trigger that runs a script every time a student submits a course evaluation form. It kicks off the feedback loop automatically for me.
#7. It’s free
Apps Script is free to use, and all you need to get started is a Google account.
So, if you use Gmail, you can start coding in Apps Script in your browser, for free, right now. If you use Sheets, you can start. If you use Docs, you can start.
It’s literally only one more click to open up the Script Editor and start coding.
Apps Script is supremely useful in its own right. It’s worth learning so you can automate tedious parts of your G Suite workflows, or build useful tools for yourself or colleagues at work.
It’s challenging enough that you’ll never run out of ideas or avenues to explore, but friendly enough you can make inroads pretty quickly.
I love that it’s hassle-free to set up and get started, and I’m sure you’ll come to love that too.
If you’re ready to start your Apps Script journey today, check out Apps Script Blastoff—a free, introductory Apps Script course that over 4,000 other folks have used to begin their coding journeys.
About the author
Ben Collins is an educator, data analyst and Google Developer Expert focused on G Suite Technology, specifically Google Sheets, Apps Script, and Data Studio. He is the founder of The Collins School of Data.
He creates online courses and writes about working with data, with a particular focus on tutorials for data analytics, automation, and dashboards.
Ben previously taught Data Analytics for General Assembly and began his career as a forensic accountant.
The tongue went along the ellipse of the labia, reaching the clitoris and dropping down. Finally, the tongue burst into the vagina, licking the sensitive walls, the pelvis went up and down, fucking the slit with my tongue. The member pressed the head against the clitoris, it shook from such a touch, the head went shallowly and rubbed the.
You will also be interested:
- Chinese food macon ga
- Functional medicine richmond va
- Eld for sale near me
- San diego california weather
- Amd rx 6900 xt
- Trials armor destiny 2
- Fake health insurance card generator
In the evening I walked after training. Nastya called me. I heard her scared voice, heard crying and was very scared.