GitHub Joins Amicus Brief Warning Of Systemic Risk From Private Sector Offensive Actors

Today, GitHub joined an  amicus brief  in NSO v. WhatsApp,  opposing the expansion of foreign sovereign immunity to private cyber-surveillance companies that act on behalf of foreign governments. GitHub joined alongside Cisco, Google, LinkedIn, Microsoft, VMware, and the Internet Association against immunity for private sector offensive actors (PSOAs). Law and policy shape the software ecosystem. A policy of immunity would increase systemic risk to the ecosystem by fostering the cyber-surveillance tools market and expanding the use of such tools by governments, including in attacks on individuals and infrastructure.

#policy #github

What is GEEK

Buddha Community

GitHub Joins Amicus Brief Warning Of Systemic Risk From Private Sector Offensive Actors

Today, GitHub joined an  amicus brief  in NSO v. WhatsApp,  opposing the expansion of foreign sovereign immunity to private cyber-surveillance companies that act on behalf of foreign governments. GitHub joined alongside Cisco, Google, LinkedIn, Microsoft, VMware, and the Internet Association against immunity for private sector offensive actors (PSOAs). Law and policy shape the software ecosystem. A policy of immunity would increase systemic risk to the ecosystem by fostering the cyber-surveillance tools market and expanding the use of such tools by governments, including in attacks on individuals and infrastructure.

#policy #github

10 Writing steps to create a good project brief - Mobile app development

Developing a mobile application can often be more challenging than it seems at first glance. Whether you’re a developer, UI designer, project lead or CEO of a mobile-based startup, writing good project briefs prior to development is pivotal. According to Tech Jury, 87% of smartphone users spend time exclusively on mobile apps, with 18-24-year-olds spending 66% of total digital time on mobile apps. Of that, 89% of the time is spent on just 18 apps depending on individual users’ preferences, making proper app planning crucial for success.

Today’s audiences know what they want and don’t want in their mobile apps, encouraging teams to carefully write their project plans before they approach development. But how do you properly write a mobile app development brief without sacrificing your vision and staying within the initial budget? Why should you do so in the first place? Let’s discuss that and more in greater detail.

Why a Good Mobile App Project Brief Matters?

It’s worth discussing the significance of mobile app project briefs before we tackle the writing process itself. In practice, a project brief is used as a reference tool for developers to remain focused on the client’s deliverables. Approaching the development process without written and approved documentation can lead to drastic, last-minute changes, misunderstanding, as well as a loss of resources and brand reputation.

For example, developing a mobile app that filters restaurants based on food type, such as Happy Cow, means that developers should stay focused on it. Knowing that such and such features, UI elements, and API are necessary will help team members collaborate better in order to meet certain expectations. Whether you develop an app under your brand’s banner or outsource coding and design services to would-be clients, briefs can provide you with several benefits:

• Clarity on what your mobile app project “is” and “isn’t” early in development
• Point of reference for developers, project leads, and clients throughout the cycle
• Smart allocation of available time and resources based on objective development criteria
• Streamlined project data storage for further app updates and iterations

Writing Steps to Create a Good Mobile App Project Brief

1. Establish the “You” Behind the App

Depending on how “open” your project is to the public, you will want to write a detailed section about who the developers are. Elements such as company name, address, project lead, project title, as well as contact information, should be included in this introductory segment. Regardless of whether you build an in-house app or outsource developers to a client, this section is used for easy document storage and access.

#android app #ios app #minimum viable product (mvp) #mobile app development #web development #how do you write a project design #how to write a brief #how to write a project summary #how to write project summary #program brief example #project brief #project brief example #project brief template #project proposal brief #simple project brief template

System Databases in SQL Server

Introduction

In SSMS, we many of may noticed System Databases under the Database Folder. But how many of us knows its purpose?. In this article lets discuss about the System Databases in SQL Server.

System Database

Fig. 1 System Databases

There are five system databases, these databases are created while installing SQL Server.

• Master
• Model
• MSDB
• Tempdb
• Resource

Master

• This database contains all the System level Information in SQL Server. The Information in form of Meta data.
• Because of this master database, we are able to access the SQL Server (On premise SQL Server)

Model

• This database is used as a template for new databases.
• Whenever a new database is created, initially a copy of model database is what created as new database.

MSDB

• This database is where a service called SQL Server Agent stores its data.
• SQL server Agent is in charge of automation, which includes entities such as jobs, schedules, and alerts.

TempDB

• The Tempdb is where SQL Server stores temporary data such as work tables, sort space, row versioning information and etc.
• User can create their own version of temporary tables and those are stored in Tempdb.
• But this database is destroyed and recreated every time when we restart the instance of SQL Server.

Resource

• The resource database is a hidden, read only database that holds the definitions of all system objects.
• When we query system object in a database, they appear to reside in the sys schema of the local database, but in actually their definitions reside in the resource db.

#sql server #master system database #model system database #msdb system database #sql server system databases #ssms #system database #system databases in sql server #tempdb system database

Apache Spark’s Join Algorithms

One of the most frequently used transformations in Apache Spark is Join operation. Joins in Apache Spark allow the developer to combine two or more data frames based on certain (sortable) keys. The syntax for writing a join operation is simple but some times what goes on behind the curtain is lost. Internally, for Joins Apache Spark proposes a couple of Algorithms and then chooses one of them. Not knowing what these internal algorithms are, and which one does spark choose might make a simple Join operation expensive.

While opting for a Join Algorithm, Spark looks at the size of the data frames involved. It considers the Join type and condition specified, and hint (if any) to finally decide upon the algorithm to use. In most of the cases, Sort Merge join and Shuffle Hash join are the two major power horses that drive the Spark SQL joins. But if spark finds the size of one of the data frames less than a certain threshold, Spark puts up Broadcast Join as it’s top contender.

Broadcast Hash Join

Looking at the Physical plan of a Join operation, a Broadcast Hash Join in Spark looks like this

The above plan shows that the data frame from one of the branches broadcasts to every node containing the other data frame. In each node, Spark then performs the final Join operation. This is Spark’s per-node communication strategy.

Spark uses the Broadcast Hash Join when one of the data frame’s size is less than the threshold set in spark.sql.autoBroadcastJoinThreshold. It’s default value is 10 Mb, but can be changed using the following code

spark.conf.set("spark.sql.autoBroadcastJoinThreshold", 100 * 1024 * 1024)

This algorithm has the advantage that the other side of the join doesn’t require any shuffle. If this other side is very large, not doing the shuffle will bring notable speed-up as compared to other algorithms that would have to do the shuffle.

Broadcasting large datasets can also lead to timeout errors. A configuration spark.sql.broadcastTimeout sets the maximum time that a broadcast operation should take, past which the operation fails. The default timeout value is 5 minutes, but it can be set as follows:

spark.conf.set("spark.sql.broadcastTimeout", time_in_sec)

Sort Merge Join

If neither of the data frames can be broadcasted, then Spark resorts to Sort Merge Join. This algorithm uses the node-node communication strategy, where Spark shuffles the data across the cluster.

Sort Merge Join requires both sides of the join to have correct partitioning and order. Generally, this is ensured by** shuffle and sort** in both branches of the join as depicted below

#apache spark #scala #tech blogs #broadcast join #join opertaions #join optimization #joins in spark #shuffled hash join #sort merge join

How to Compare Multiple GitHub Projects with Our GitHub Stats tool

If you have project code hosted on GitHub, chances are you might be interested in checking some numbers and stats such as stars, commits and pull requests.

You might also want to compare some similar projects in terms of the above mentioned stats, for whatever reasons that interest you.

We have the right tool for you: the simple and easy-to-use little tool called GitHub Stats.

Let’s dive right in to what we can get out of it.

Getting started

This interactive tool is really easy to use. Follow the three steps below and you’ll get what you want in real-time:

1. Head to the GitHub repo of the tool

2. Enter as many projects as you need to check on

3. Hit the Update button beside each metric

In this article we are going to compare three most popular machine learning projects for you.

#github #tools #github-statistics-react #github-stats-tool #compare-github-projects #github-projects #software-development #programming