Microsoft Education gets to do something pretty incredible every day: work with educators across the world to create engaging classroom experiences. At the heart of our products is the brilliance that teachers and students always bring to the table.

So, for Back to School 2018, we’re returning some of that infectious learning energy with some very exciting updates in Microsoft Teams for Education. Thanks in huge part to the tireless work and feedback of teachers and students across the world, #MicrosoftEDU is thrilled to announce 10 fresh new features in Teams for the upcoming school year (and beyond ?).

And don’t forget, teachers and students can get started with Teams for free as part of Office 365 Education.

1. Rubric grading now available

Introducing an all-new way to increase transparency in assessment:

[embedded content]

Giving educators the tools to provide great feedback means everything to us. So, when it comes to rubric grading, we listened to how important it was to you – and made it happen. Rubric grading is now available to every educator! Built directly into Teams for Education, rubric grading helps increase assignment transparency for students and allows you to give more meaningful feedback.

These feedback mechanisms not only help students learn and improve their work, but they’re also a consistent and transparent way for teachers to grade. Now, inside of Teams, you can customize your grading criteria with your own rubric to enable skills-based grading of your assignments. 

2. Mobile Assignments experience

We know mobile is huge for our students and teachers, so we’ve made a meaningful update to our iOS and Android apps designed to save students and teachers time. You can now access all your assignments directly when you launch the app and see a simplified list of upcoming tasks across all your classes. Students can work on their assignments directly on their phones and turn in.

Teachers can also create new assignments right from our apps, so it doesn’t matter if you’re on the bus or working from home. You can always keep your students up-to-date and on-schedule.

3. Archiving teams

If you’ve been using Teams for a while, you probably have some older teams piling up from the previous school year that you’d like to get out of the way. Instead of deleting the team altogether, you can now archive the team (essentially placing it in a frozen read-only state). This way, you can go back and reference what you covered last year any time you want. Learn how.

4. Reuse assignments – again (and again and again)

We love hearing from teachers that create assignments for their classes every day. And we know teachers using Teams have been creating millions of assignments. In doing this, they are fully building out their learning activities with instructions, attachments, and customization to share with their students.

Well, wouldn’t it be great if you could reuse these assignments over and over (and over and over) again? It would, which is why we’re so excited to introduce the ability to reuse assignments from current or archived Class Teams.

5. All-new Flipgrid app

Microsoft Teams has caught a serious case of #FlipgridFever (and the only prescription is more Flipgrid).

Just a couple days ago our friends took the stage at #FlipgridLIVE and announced the latest and greatest new features to create the perfect space for your students to share their brilliance. Check out the colorful, powerful, and emoji-ful ? Grids + Topics! Plus: see how you can unleash creativity with the new Flipgrid Recorder + Player.

We are truly #BetterTogether with the Flipgrid community. All these new features are built directly into your class, staff or PLC teams – you just need to add the Flipgrid app. Since Flipgrid joined Microsoft Education, we’ve made Flipgrid completely free for every educator and student in the world! Try it out today.

6. New Class and Staff Notebook Tab App

To help save teachers more time when using OneNote Class and Staff Notebooks inside Microsoft Teams, we’re releasing a few key updates. Teachers will enjoy the new and improved Class and Staff Notebook settings directly inside Microsoft Teams – just select “Manage Notebooks” in the tab menu. Plus, we’ve improved the Class Notebook toolbar and added a new Staff Notebook toolbar, specifically for staff teams. In addition, page distribution is now fully supported in the Teams desktop app!

7. Cloud recording

From faculty meetings to online office hours, built-in video meetings in Teams make collaboration easy, powered by Microsoft Stream. Ever wanted to record that meeting or online lecture? Now you can provide one-click meeting recordings with automatic transcription and timecoding, which also displays captions and lets team members search within the conversation, and play back all or part of the meeting.

8. Dark Mode

It’s easy on the eyes, and dark to the core. Dark mode is a dramatic new look that helps you focus on your schoolwork. Choose what’s best for you: the familiar light appearance, the new dark mode, or even high-contrast mode.

9. Immersive Reader in Teams messages (coming soon)

Teachers have been blown away by the power Immersive Reader has in helping to build confidence for emerging readers and for those who struggle to read grade-level texts. We’re thrilled to be bringing the Immersive Reader experience to Teams! Once Immersive Reader is added in the next few weeks, you will be able to use it with any message in Teams.

10. Forms in Assignments

Assignments in Teams is about to get a new best friend: Microsoft Forms. Later this month, we’re launching the Assignments + Forms integration, giving you the power to seamlessly distribute assessments through your Assignments app – then use Forms reporting for auto-grading, feedback, and scores.

Extra credit: Email digest for guardians/parents (coming soon)

Soon, guardians will be able to stay up-to-date with their student’s progress. The new guardian email digest provides a quick look of the previous week’s assignment progress (detailing the missing or completed work), plus the upcoming week’s assignments.

Woohoo! The love for Teams continues. We have even more announcements coming this fall, so be sure to follow @MicrosoftTeams, @MicrosoftEDU, or reach out with questions to me directly @justinchando! ?

Get started with Teams today, free for students and teachers.

Football fans, rejoice! The next iteration of Sports Interactive’s Football Manager series has been announced. Football Manager 2019 will be launching on PC, MacOS Android and iOS on November 2^nd.

[embedded content]

As with Football Manager 2018, the mobile version of Football Manager 2019 will come in two flavours:

• Football Manager Touch 2019 will be a direct port of the PC game, and only works on tablets. It costs more (FM Touch 18 goes for $19.99 at full price), and has higher spec requirements, but is essentially the PC game on your tablet.
• Football Manager Mobile 2019 will be a slim lined/adapted version of the full game for mobile. It’ll be iOS Universal and work on phones generally, have lower spec requirements and will be priced in-line with other premium mobile experiences. FM Mobile 18 is $8.99 at full price.

There’re quite a few changes coming in FM 2019 – for the first time there will be licensed German DFL teams, for one thing, and they’ll be talking about more concrete game changes towards the end of September.

We have yet to get around to actually reviewing 2018’s FM Mobile and FM Touch releases, so we’ll try and plug those gaps as soon as possible.

Make a splash with WAVERACER https://t.co/JW0Aei8tV0 (Legendary)! ?
Join us in Busan for Summer Games, kicking off August 9. pic.twitter.com/0IO0BKZMuc

— Overwatch (@PlayOverwatch) August 4, 2018

Break enemy lines with Gridironhardt Reinhardt (Legendary)! ?
Join us in Busan for Summer Games, kicking off August 9. pic.twitter.com/DIHj9XmaBv

— Overwatch (@PlayOverwatch) August 4, 2018

In this systemd tutorial series, we have already talked about systemd timer units to some degree, but, before moving on to the sockets, let’s look at three examples that illustrate how you can best leverage these units.

Simple cron-like behavior

This is something I have to do: collect popcon data from Debian every week, preferably at the same time so I can see how the downloads for certain applications evolve. This is the typical thing you can have a cron job do, but a systemd timer can do it too:

# cron-like popcon.timer [Unit] Description= Says when to download and process popcons [Timer] On‌Calendar= Thu *-*-* 05:32:07 Unit= popcon.service [Install] WantedBy= basic.target

The actual popcon.service runs a regular wget job, so nothing special. What is new in here is the OnCalendar= directive. This is what lets you set a service to run on a certain date at a certain time. In this case, Thu means “run on Thursdays” and the *-*-* means “the exact date, month and year don’t matter“, which translates to “run on Thursday, regardless of the date, month or year“.

Then you have the time you want to run the service. I chose at about 5:30 am CEST, which is when the server is not very busy.

If the server is down and misses the weekly deadline, you can also work an anacron-like functionality into the same timer:

# popcon.timer with anacron-like functionality [Unit] Description=Says when to download and process popcons [Timer] Unit=popcon.service On‌Calendar=Thu *-*-* 05:32:07

Persistent=true [Install] WantedBy=basic.target

When you set the Persistent= directive to true, it tells systemd to run the service immediately after booting if the server was down when it was supposed to run. This means that if the machine was down, say for maintenance, in the early hours of Thursday, as soon as it is booted again, popcon.service will be run immediately and then it will go back to the routine of running the service every Thursday at 5:32 am.

So far, so straightforward.

Delayed execution

But let’s kick thing up a notch and “improve” the systemd-based surveillance system. Remember that the system started taking pictures the moment you plugged in a camera. Suppose you don’t want pictures of your face while you install the camera. You will want to delay the start up of the picture-taking service by a minute or two so you can plug in the camera and move out of frame.

To do this; first change the Udev rule so it points to a timer:

ACTION=="add", SUBSYSTEM=="video4linux", ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="e207", TAG+="systemd", ENV{SYSTEMD_WANTS}="picchanged.timer", SYMLINK+="mywebcam", MODE="0666"

The timer looks like this:

# picchanged.timer [Unit] Description= Runs picchanged 1 minute after the camera is plugged in [Timer] On‌ActiveSec= 1 m

Unit= picchanged.path [Install]

WantedBy= basic.target

The Udev rule gets triggered when you plug the camera in and it calls the timer. The timer waits for one minute after it starts (OnActiveSec= 1 m) and then runs picchanged.path, which monitors to see if the master image changes. The picchanged.path is also in charge of pulling in the webcam.service, the service that actually takes the picture.

Start and stop Minetest server at a certain time every day

In the final example, let’s say you have decided to delegate parenting to systemd. I mean, systemd seems to be already taking over most of your life anyway. Why not embrace the inevitable?

So you have your Minetest service set up for your kids. You also want to give some semblance of caring about their education and upbringing and have them do homework and chores. What you want to do is make sure Minetest is only available for a limited time (say from 5 pm to 7 pm) every evening.

This is different from “starting a service at certain time” in that, writing a timer to start the service at 5 pm is easy…:

# minetest.timer [Unit]

Description= Runs the minetest.service at 5pm everyday [Timer]

On‌Calendar= *-*-* 17:00:00 Unit= minetest.service [Install]

WantedBy= basic.target

… But writing a counterpart timer that shuts down a service at a certain time needs a bigger dose of lateral thinking.

Let’s start with the obvious — the timer:

# stopminetest.timer [Unit]

Description= Stops the minetest.service at 7 pm everyday [Timer]

On‌Calendar= *-*-* 19:05:00 Unit= stopminetest.service [Install]

WantedBy= basic.target

The tricky part is how to tell stopminetest.service to actually, you know, stop the Minetest. There is no way to pass the PID of the Minetest server from minetest.service. and there are no obvious commands in systemd’s unit vocabulary to stop or disable a running service.

The trick is to use systemd’s Conflicts= directive. The Conflicts= directive is similar to systemd’s Wants= directive, in that it does exactly the opposite. If you have Wants=a.service in a unit called b.service, when it starts, b.service will run a.service if it is not running already. Likewise, if you have a line that reads Conflicts= a.service in your b.service unit, as soon as b.service starts, systemd will stop a.service.

This was created for when two services could clash when trying to take control of the same resource simultaneously, say when two services needed to access your printer at the same time. By putting a Conflicts= in your preferred service, you could make sure it would override the least important one.

You are going to use Conflicts= a bit differently, however. You will use Conflicts= to close down cleanly the minetest.service:

# stopminetest.service [Unit]

Description= Closes down the Minetest service

Conflicts= minetest.service [Service]

Type= oneshot

ExecStart= /bin/echo "Closing down minetest.service"

The stopminetest.service doesn’t do much at all. Indeed, it could do nothing at all, but just because it contins that Conflicts= line in there, when it is started, systemd will close down minetest.service.

There is one last wrinkle in your perfect Minetest set up: What happens if you are late home from work, it is past the time when the server should be up but playtime is not over? The Persistent= directive (see above) that runs a service if it has missed its start time is no good here, because if you switch the server on, say at 11 am, it would start Minetest and that is not what you want. What you really want is a way to make sure that systemd will only start Minetest between the hours of 5 and 7 in the evening:

# minetest.timer [Unit]

Description= Runs the minetest.service every minute between the hours of 5pm and 7pm [Timer]

OnCalendar= *-*-* 17..19:*:00

Unit= minetest.service [Install]

WantedBy= basic.target

The line OnCalendar= *-*-* 17..19:*:00 is interesting for two reasons: (1) 17..19 is not a point in time, but a period of time, in this case the period of time between the times of 17 and 19; and (2) the * in the minute field indicates that the service must be run every minute. Hence, you would read this as “run the minetest.service every minute between 5 and 7 pm“.

There is still one catch, though: once the minetest.service is up and running, you want minetest.timer to stop trying to run it again and again. You can do that by including a Conflicts= directive into minetest.service:

# minetest.service [Unit]

Description= Runs Minetest server

Conflicts= minetest.timer [Service]

Type= simple

User= <your user name> ExecStart= /usr/bin/minetest --server ExecStop= /bin/kill -2 $MAINPID [Install]

WantedBy= multi-user.targe

The Conflicts= directive shown above makes sure minetest.timer is stopped as soon as the minetest.service is successfully started.

Now enable and start minetest.timer:

systemctl enable minetest.timer

systemctl start minetest.timer

And, if you boot the server at, say, 6 o’clock, minetest.timer will start up and, as the time falls between 5 and 7, minetest.timer will try and start minetest.service every minute. But, as soon as minetest.service is running, systemd will stop minetest.timer because it “conflicts” with minetest.service, thus avoiding the timer from trying to start the service over and over when it is already running.

It is a bit counterintuitive that you use the service to kill the timer that started it up in the first place, but it works.

Conclusion

You probably think that there are better ways of doing all of the above. I have heard the term “overengineered” in regard to these articles, especially when using systemd timers instead of cron.

But, the purpose of this series of articles is not to provide the best solution to any particular problem. The aim is to show solutions that use systemd units as much as possible, even to a ridiculous length. The aim is to showcase plenty of examples of how the different types of units and the directives they contain can be leveraged. It is up to you, the reader, to find the real practical applications for all of this.

Be that as it may, there is still one more thing to go: next time, we’ll be looking at sockets and targets, and then we’ll be done with systemd units.

Learn more about Linux through the free “Introduction to Linux” course from The Linux Foundation and edX.

This year Unity polled the leads of 1,445 independent game studios, including some that don’t use the Unity game engine, to try and capture a snapshot of the state of indie game dev by exploring things like studio size, project type, favored marketing platforms, monetization plans, and more.

While the survey sample included teams of many sizes (from 2-50 people), respondents tended to be on the smaller side: 78 percent of the studios polled employ less than 10 developers, with 59 percent only employing 2-5 people, including freelancers and contractors.

Overall, 46 percent of teams rent or own an office space but 45 percent offer employees the option to work remotely. Unity notes that younger studios and those with smaller teams tend to favor remote work, with 84 percent of companies on board with remote work employing only two to five employees.

Meanwhile, only 25 percent of studios under 6 months old own or rent an office space. The majority, 64 percent, instead opt to work remotely while 61 percent of studios over 2 years old own or rent an office. 

Looking at projects being developed, 72 percent of devs list PC as the target platform of their primary project, ahead of 57 percent for mobile, 29 percent for console, 24 percent for VR, and 16 percent for AR. Unity goes on to note that there was naturally some overlap between PC- and console-targeting devs; of those that chose PC for their platform of choice, nearly 38 percent said they were also going for a console release.

67 percent of surveyed teams plan to self-publish their primary project, with 81 percent of those self-publishing devs having 10 or fewer employees and 63 percent employing 5 or less. The majority of devs, 53 percent, plan to monetize their games through a ‘premium’ one-time-payment model, while 36 percent instead plan to adopt a freemium model.

The full report offers a deeper look into many of these topics, including breakdowns of the different disciplines that make up indie studios and how those teams approach budgeting and keeping the lights on.