https://www.datacamp.com/community/podcast/building-data-science-teams

<p>Drew Conway speaks with Hugo about how to build data science teams, along with the unique challenges of building data science products for industrial users.&nbsp;</p>

Drew Conway speaks with Hugo about how to build data science teams, along with the unique challenges of building data science products for industrial users. 

Building Data Science Teams

https://www.datacamp.com/community/news/jupyter-notebook-in-visual-studio-code-lh02y96ojgm

Jupyter Notebook like features in Microsoft's Visual Studio Editor. Generate Visuals, Graphs, Data grid and even more

Jupyter Notebook in Visual Studio Code

https://www.datacamp.com/community/news/the-pod-as-a-service-podaas-podcast-now-live-hgo1ft5w3iq

I've just launched the Pod as a Service [PODaaS] podcast! PODaaS is a podcast on emerging, trending, and state-of-the-art technologies. You can subscribe via iTunes at https://bit.ly/2Ii2hBn or Google Play at https://bit.ly/podgpof. Please subscribe & provide a rating/review!

 	The Pod as a Service [PODaaS] Podcast Now Live!

https://www.datacamp.com/community/news/python-xml-with-elementtree-beginners-guide-c0p0utrcgm

Learn how you can parse, explore, modify and populate XML files with the Python ElementTree package, for loops and XPath expressions.

Python XML with ElementTree: Beginner's Guide

https://www.datacamp.com/community/news/scalable-software-and-big-data-architecture-3-part-series-jjhiirwv6io

An in-depth series on scalable software and big data architecture that covers: application types, requirements, and components; software architectural patterns and design patterns; big data and analytics architectural patterns.

Scalable Software and Big Data Architecture (3-Part Series)

<p>SQL, also known as Structured Query Language, is a powerful tool to search through large amounts of data and return specific information for analysis. Learning SQL is crucial for anyone aspiring to be a data analyst, data engineer, or data scientist, and helpful in many other fields such as web development or marketing.</p>
<p>The good news is that SQL is easy to learn online in just one or two months—many aspiring data professionals start off with SQL and then move onto more complex programming languages like Python and R. SQL has <a href="https://codingsight.com/structured-query-language-importance-of-learning-sql/">many other benefits</a>, including its flexibility to handle millions of rows of data and its universality across disciplines and industries. Data analysis done in SQL is easy to audit and replicate, especially when compared to spreadsheet tools.</p>
<p>SQL has been around since the 1970s and is here to stay. In this article, we’ll walk you through everything you need to get started in SQL.</p>
<h2 id="what-to-know-before-you-begin">What to know before you begin</h2>
<h3 id="sql-and-relational-databases">SQL and relational databases</h3>
<p>Many organizations use a relational database to store and <a href="https://www.youtube.com/watch?v=FR4QIeZaPeM">process large amounts of data</a>. With SQL (pronounced either as “sequel” or as “ess-que-ell”), you can “query,” or ask questions of, the data in a relational database. In other words, SQL is the programming language used to communicate with these databases. Each database uses its own SQL dialect but they all share the same basic syntax.</p>
<h3 id="different-sql-dialects">Different SQL dialects</h3>
<p>Although all SQL languages share a basic structure, some of the specific commands and styles can differ (kind of like how different regions of the U.S. can refer to a carbonated sugary beverage as either a “soda,” a “pop,” or a “coke”). With so many SQL dialects, <a href="https://www.datacamp.com/community/blog/sql-differences">it can be hard to know where to start</a>. Popular dialects include <a href="https://www.mysql.com/">MySQL</a>, <a href="https://www.sqlite.org/about.html">SQLite</a>, and <a href="https://www.microsoft.com/en-us/sql-server">SQL Server</a>, but we recommend starting with <a href="https://www.postgresql.org/">PostgreSQL</a>—it’s the closest to <a href="https://www.sqlstyle.guide/">standard SQL syntax</a> so it’s easily adapted to other dialects. Of course, if your company already has a database, you should learn the compatible dialect.</p>
<h2 id="4-steps-to-learn-sql">4 steps to learn SQL</h2>
<p>Learning SQL doesn’t require prior programming knowledge, so it’s great for beginners. Devote a couple of weeks to these four steps, and you’ll be on your way to your dream <a href="https://www.dataquest.io/blog/10-data-analytics-jobs/">analytics career</a>.</p>
<h3 id="1-learn-basic-sql-syntax">1. Learn basic SQL syntax</h3>
<p>You’ll need to understand the basics of <a href="https://www.w3schools.com/sql/sql_syntax.asp">SQL syntax</a>, including the functions SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, and LIMIT. The different SQL dialects use very similar syntax, with a few exceptions.</p>
<p>With SQL, the order of written code differs from the <a href="https://www.sisense.com/blog/sql-query-order-of-operations/">order of execution</a>. So you’ll need to understand proper query structure and the order in which queries must be written.</p>
<h4 id="sql-order-of-execution">SQL Order of Execution</h4>
<p><center><a href="https://www.datacamp.com/"><img src="https://res.cloudinary.com/dyd911kmh/image/upload/f_auto,q_auto:best/v1601660344/SQL_order_of_execution_blue_x7byqj.png" /></a></center><br></p>
<p>TL;DR: Your query will always need a SELECT and a FROM statement (to identify which columns you want returned from which table)—the others are optional.</p>
<h3 id="2-take-an-online-sql-course">2. Take an online SQL course</h3>
<p>You can learn how to use SQL in production even before accessing a database. The best way to learn SQL is with hands-on courses that introduce core concepts and get you familiar with SQL code. I may be biased, but DataCamp’s <a href="https://www.datacamp.com/courses/introduction-to-sql">Introduction to SQL</a> course is a brilliant overview—it’s the first course in our <a href="https://www.datacamp.com/tracks/sql-fundamentals">SQL Fundamentals</a> skill track. W3Schools’ <a href="https://www.w3schools.com/sql/default.asp">SQL Tutorial</a>, Codecademy’s <a href="https://www.codecademy.com/learn/learn-sql">Learn SQL</a> course, and Khan Academy’s <a href="https://www.khanacademy.org/computing/computer-programming/sql">Intro to SQL</a> are also excellent.</p>
<h3 id="3-start-practicing-with-real-data">3. Start practicing with real data</h3>
<p>The best way to master SQL is by practicing in your own environment—so you’ll need to install a database. If your company already uses a database, you should go through the proper channels to install it on your system. You (or your company) may be more comfortable working in a duplicate database that is not connected to live data at first—and that’s ok!</p>
<p>You can also install a free database, like <a href="https://www.pgadmin.org/download/">PostgreSQL (PGadmin)</a>, <a href="https://www.sqlite.org/download.html">SQLite</a>, or <a href="https://dev.mysql.com/downloads/mysql/">MySQL</a>; or follow our step-by-step tutorial on <a href="https://www.datacamp.com/community/tutorials/how-to-install-sql-server">how to install SQL Server</a>.</p>
<p>Then, you’ll need some data to play with. Preferably, you’d use real data from your company so you can start exploring data that matters to you. Alternatively, you can download a public dataset through <a href="https://www.kaggle.com/datasets">Kaggle</a> or <a href="https://github.com/freeCodeCamp/open-data">freeCodeCamp Open Data</a>.</p>
<h3 id="4-prepare-for-a-job-that-requires-sql">4. Prepare for a job that requires SQL</h3>
<p>So many roles today require SQL knowledge, and coding on a daily basis is the best way to become an expert. Before you start applying to jobs, you can plug any gaps in your SQL repertoire with DataCamp’s <a href="https://assessment.datacamp.com/data-analysis-in-sql">Data Analysis in SQL</a> skill assessment. As you’re applying to positions, make sure to <a href="https://zety.com/blog/sql-developer-resume-example">tailor your resume to the role</a> to stand out. And if you land that coveted job interview, you should know how to answer the <a href="https://www.sqlbot.co/blog/sql-interview-questions">top 13 SQL interview questions</a>.</p>
<h2 id="practice-practice-practice-">Practice, practice, practice!</h2>
<p>Learning SQL is like learning any other language—it takes constant practice to stay sharp and learn new things! Set aside some time every day or at least once a week to <a href="https://www.hackerrank.com/domains/sql">practice your SQL coding skills</a>. Keep at it and you’ll be a SQL superstar in no time!</p>


https://www.datacamp.com/community/blog/how-to-learn-sql

Here’s everything you need to know to get started in SQL.

How to Learn SQL

<p class="headline">One of the core features of <a href="https://www.rdocumentation.org/">RDocumentation.org</a> is its search functionality. From the start, we wanted to have a super simple search bar that finds what you are looking for, without a complex form asking for a package name, function name, versions or anything else. Just a simple search bar.</p>

<p class="headline">In today&#39;s <a href="https://tech.datacamp.com/">technical blog</a>&nbsp;post, we will highlight the technologies and techniques that we use to provide relevant and meaningful results to our users.</p>

<h2 id="elasticsearch">Elasticsearch</h2>

<p>RDocumentation.org uses <a href="https://www.elastic.co/products/elasticsearch">Elasticsearch</a> to index and search through all R packages and topics.</p>

<blockquote>
<p>Elasticsearch is an open-source, scalable, distributed, enterprise-grade search engine.</p>
</blockquote>

<p>Elasticsearch is perfect for querying documentation because it doesn&rsquo;t use conventional SQL data, but it&nbsp;stores documents in a JSON-like data structure instead. Each document is just a set of <em>key-value</em> pairs with simple data types (strings, numbers, lists, dates, &hellip;). Its distributed nature means Elasticsearch can be extremely fast.</p>

<p>An Elasticsearch cluster can have multiple indexes and each index can have multiple <em>document types</em>. A document type just describes what the structure of the document should look like. To learn more about Elasticsearch types, you can visit <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/mapping.html">the guide on elastic.co</a>.</p>

<p>RDocumentation.org uses three different types: <code class="highlighter-rouge">package_version</code>, <code class="highlighter-rouge">topic</code>, and <code class="highlighter-rouge">package</code>. The first 2 are the main ones; let&rsquo;s discuss <code class="highlighter-rouge">package</code> later.</p>

<p>Because RDocumentation.org is open-source, you can see the Elasticsearch&rsquo;s mappings in our <a href="https://github.com/datacamp/RDocumentation-elasticsearch/blob/master/mappings_rdoc.json">github repo</a>.&nbsp;</p>

<h3 id="package_version-type">package_version type</h3>

<p>The <code class="highlighter-rouge">package_version</code> type is like a translation of the <code class="highlighter-rouge">DESCRIPTION</code> file of a package, it features the main field that one can find in there; <code class="highlighter-rouge">package_name</code>, <code class="highlighter-rouge">version</code>, <code class="highlighter-rouge">title</code>, <code class="highlighter-rouge">description</code>, <code class="highlighter-rouge">release_date</code>, <code class="highlighter-rouge">license</code>, <code class="highlighter-rouge">url</code>, <code class="highlighter-rouge">copyright</code>, <code class="highlighter-rouge">created_at</code>, <code class="highlighter-rouge">updated_at</code>, <code class="highlighter-rouge">latest_version</code>, <code class="highlighter-rouge">maintainer</code> and <code class="highlighter-rouge">collaborators</code>. The <code class="highlighter-rouge">maintainer</code> and <code class="highlighter-rouge">collaborators</code> are extracted from the <code class="highlighter-rouge">Authors</code> field in the <code class="highlighter-rouge">DESCRIPTION</code> file</p>

<h3 id="topic-type">topic type</h3>

<p>The topic documents are parsed from the <code class="highlighter-rouge">Rd</code> files, the standard format of documentation in R. The <code class="highlighter-rouge">topic</code> type has the following keys: <code class="highlighter-rouge">name</code>, <code class="highlighter-rouge">title</code>, <code class="highlighter-rouge">description</code>, <code class="highlighter-rouge">usage</code>, <code class="highlighter-rouge">details</code>, <code class="highlighter-rouge">value</code>, <code class="highlighter-rouge">references</code>, <code class="highlighter-rouge">note</code>, <code class="highlighter-rouge">author</code>, <code class="highlighter-rouge">seealso</code>, <code class="highlighter-rouge">examples</code>, <code class="highlighter-rouge">created_at</code>, <code class="highlighter-rouge">updated_at</code>, <code class="highlighter-rouge">sections</code>, <code class="highlighter-rouge">aliases</code> and <code class="highlighter-rouge">keywords</code>.</p>

<h2 id="scoring-in-elasticsearch">Scoring in Elasticsearch</h2>

<p>Before doing any scoring, Elasticseach first tries to reduce the set of candidates by checking if the document actually matches the query. Basically, a query is a word (or a set of words). Based on the query setting, Elasticsearch searches for a match in certain fields of certain types.</p>

<p>However, a match does not necessarily mean that the document is relevant; the same word can have different meanings in different contexts. Based on the query settings, we can filter by type and field, and include more contextual information. This contextual information will improve the relevancy and this is where scoring comes into place.</p>

<p>Elasticsearch uses <a href="http://lucene.apache.org/core/">Lucene</a> under the hood, so the scoring is based on Lucene&rsquo;s <a href="https://lucene.apache.org/core/4_6_0/core/org/apache/lucene/search/similarities/TFIDFSimilarity.html#formula_coord">Practical Scoring Function</a> which brings together some models like the <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/scoring-theory.html#tfidf"><em>TF-IDF</em></a>, <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/scoring-theory.html#vector-space-model"><em>Vector Space Model</em></a> and <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/scoring-theory.html#boolean-model"><em>Boolean Model</em></a> to score the document.</p>

<p>If you want to lean more about how that function is used in Elasticsearch, you can check out <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/practical-scoring-function.html">this section of elastic.co guide</a>.</p>

<p>One way to improve relevancy is to apply a boost to some fields. For example, in the RDocumentation.org full search, we naturally boost fields like <code class="highlighter-rouge">package_name</code> and <code class="highlighter-rouge">title</code> for packages and <code class="highlighter-rouge">aliases</code> and <code class="highlighter-rouge">name</code> for topics.</p>

<h3 id="boosting-the-popular-documents">Boosting the popular documents</h3>

<p>Another effective way to improve relevancy is to boost documents based on their popularity. The idea behind that is that if a package is more popular, the user is more likely to search for this package. Showing the more populars packages first will increase the probability that we show what the user is actually looking for.</p>

<h4 id="using-downloads-as-a-popularity-measure">Using downloads as a popularity measure</h4>

<p>There are multiple ways to measure popularity. We could use direct measures like votes or rankings that users give (like ratings on Amazon products), or indirect measures like the number of items sold or the number of views (for YouTube videos).</p>

<p>At RDocumentation.org, we chose the latter. More specifically, we use the number of downloads as a measure of popularity. Indirect measures are typically easier to collect because they don&rsquo;t require active user input.</p>

<h4 id="timeframing">Timeframing</h4>

<p>One problem that arises when using the number of downloads is that old packages will naturally have more total downloads than newer packages. That does not mean that they are more popular, however, they have just been around longer. What if a package was very popular years ago, but has now become obsolete and is no longer being actively used by the community?</p>

<p>To solve this problem, we only take into account the number of downloads in the last month. That way, older packages&rsquo; popularity score is not artificially boosted, and obsolete packages will quickly fade out.</p>

<h4 id="direct-vs-indirect-downloads">Direct vs Indirect downloads</h4>

<p>Another problem arises from reverse dependencies. R packages typically depend on a wide range of other packages. Packages with a lot of reverse dependencies will get downloaded way more than others. However, these packages are typically more low-level and are not used directly by the end-user. We have to watch out to not give their number of downloads too much weight.</p>

<p>As an example, take <a href="https://www.rdocumentation.org/packages/Rcpp/versions/0.12.9">Rcpp</a>. Over 70 percent of all packages on CRAN, the comprehensive R archive network, depend on this package, which obviously makes it the most downloaded R package. However, rather few R users will directly use this package and search for its documentation.</p>

<p>To solve this problem, we needed to separate <em>direct downloads</em> (downloads that happens because a user requested it) and <em>indirect downloads</em> (downloads that happen because a dependent packages was downloaded). To distinguish the direct and indirect downloads from the CRAN logs, we use the same heuristic described in the <a href="https://www.rdocumentation.org/packages/cran.stats/versions/0.1/topics/stats_logs">cran.stats package</a> by Arun Srinivasan.</p>

<p>We now have a meaningful popularity metric: <em>the number of direct downloads in the last month</em>. Elasticsearch provides an easy way to inject this additional information; for more details, check out <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/boosting-by-popularity.html">this article on elastic.co</a>.</p>

<p>The score is modified as follows:</p>

<div class="highlighter-rouge">
<pre class="highlight">
<code>new_score = old_score * log(1 + number of direct downloads in the last month)
</code></pre>
</div>

<p>We use a <code class="highlighter-rouge">log()</code> function to smooth out the <code class="highlighter-rouge">number of downloads</code> value, because each subsequent downloads has less weight; the difference between 0 and 1000 downloads should have a bigger impact on a popularity score than the difference between 100,000 and 101,000 downloads.</p>

<p>This re-scoring improves the overall relevancy of the search results presented by RDocumentation.org and as a result, users can focus on reading documentation instead of searching for it.</p>

<p>If you want to find out more about how exactly the Elasticsearch query is implemented, you can take a look at the <a href="https://github.com/datacamp/RDocumentation-app">RDocumentation project on GitHub</a>. The query itself is located in the <a href="https://github.com/datacamp/RDocumentation-app/blob/master/api/controllers/SearchController.js"><code class="highlighter-rouge">SearchController</code></a>.</p>

<p>If you want to learn more about how RDocumentation.org is implemented, check out our repos:</p>

<ul>
	<li><a href="https://github.com/datacamp/RDocumentation-app">RDocumentation-app</a>: The web application running rdocumentation.org.</li>
	<li><a href="https://github.com/datacamp/RDocumentation-elasticsearch">RDocumentation-elasticsearch</a>: Configuration and feeders of the Elasticsearch server serving rdocumentation.org.</li>
	<li><a href="https://github.com/datacamp/RDocumentation">RDocumentation</a>: R package to integrate rdocumentation.org into your R workflow</li>
	<li><a href="https://github.com/datacamp/RDocumentation-lambda-worker">RDocumentation-lambda-worker</a>: AWS Lambda pipeline to parse package documentation for rdocumentation.org</li>
</ul>

<br>
<br>
<p><strong>About RDocumentation &nbsp;</strong></p>

<p><a href="http://www.rdocumentation.org" target="_blank">RDocumentation</a> aggregates help documentation for R packages from CRAN, BioConductor, and GitHub - the three most common sources of current R documentation. RDocumentation.org goes beyond simply aggregating this information, however, by bringing all of this documentation to your fingertips via the RDocumentation package. The RDocumentation package overwrites the basic help functions from the utils package and gives you access to RDocumentation.org from the comfort of your RStudio IDE. Look up the newest and most popular R packages, search through documentation and post community examples.&nbsp;</p>

<p><a href="https://www.rdocumentation.org/" target="_blank"><img alt="" src="http://community.datacamp.com.s3.amazonaws.com/community/production/ckeditor_assets/pictures/140/content_b757fa44-7112-11e6-99e0-f20e8f3f93ff.png" /></a></p>

<center><a href="https://www.rdocumentation.org/register"><strong>Create an RDocumentation account today!</strong></a></center>


https://www.datacamp.com/community/blog/rdocumentation-ranking-scoring

Learn more on how the search results on RDocumentation are generated!

This blog post details how the search results on RDocumentation are generated.

RDocumentation: Scoring and Ranking

<p><em>This article is part of a short series in which DataCamp’s Practice &amp; Mobile Team describe the process of porting a mobile application to the web. In this second article, we go in depth on our experiences of working with react-native-web on a production application.</em></p>
<p>In the first article of this series we described how our journey began with a proof-of-concept of the mobile app running in the browser. Getting this up and running involved following the <a href="https://github.com/necolas/react-native-web/blob/master/README.md">official documentation for react-native-web</a>. This involves setting up Webpack to compile a new web target from the mobile source code, and aliasing react-native so that it uses the react-native-web implementation instead. So far so good. However, we soon stumbled into another problem: the mobile source code makes references to ‘native modules’ which do not have web counterparts.</p>
<h2 id="bridging-the-gap">Bridging The Gap</h2>
<p>A native module is a bit of native code that is compiled into your app’s binary and then bridged with JS to allow interop with React Native.</p>
<p>In our case we had multiple such modules that needed to addressing. One such example is <a href="react-native-linear-gradient">react-native-linear-gradient</a>: a simple library that allows the user to render linear gradients, which is not provided by React Native core.</p>
<p>We had a couple of options to solve this problem:</p>
<ol>
<li>Branch the code so that it selectively used the native module, inline in the source code.</li>
<li>Creating a wrapper component that abstracted this branching away</li>
<li>Aliasing the native module so that no branching is required</li>
</ol>
<p>In our case we opted for option 3 as Webpack already provided a convenient way to alias modules (such as react-native itself), and this also requires less change to the application source code itself.</p>
<p>Setting up a <a href="https://webpack.js.org/configuration/resolve/#resolvealias">module alias in Webpack</a> is simple:</p>
<pre><code class="lang-js">module.exports = {
  // ...
  resolve: {
    // ...
    alias: {
      &quot;@datacamp/react-native-linear-gradient&quot;: path.resolve(
        __dirname,
        &quot;./mocked_modules/react-native-linear-gradient&quot;
      )
    }
  }
};
</code></pre>
<p>And our mocked module implementation:</p>
<pre><code class="lang-js">export default class LinearGradient extends React.PureComponent&lt;Props&gt; {
  render() {
    // See gist for full implementation
    // https://bit.ly/2X2yJzL
    // ...
  }
}
</code></pre>
<p>We repeated this process for the remaining native modules in the project. Some of them required a genuine implementation as above, whereas for others it was sufficient just to stub out the bits of the API we used and effectively doing a no-op. This was useful for modules such as <a href="https://github.com/Microsoft/react-native-code-push">react-native-code-push</a> which we had no requirement to support for the web target:</p>
<pre><code class="lang-js">import * as React from &quot;react&quot;;

const codePush = (App: React.Node) =&gt; App;

codePush.getUpdateMetaData = () =&gt; {
  return Promise.resolve(null);
};

export default codePush;
</code></pre>
<p>With the proof-of-concept now up and running, we turned our attention to the task of turning it into a real production application. The main task at hand was optimizing the mobile screens to be better suited for display and interaction on the web.</p>
<p>The dream of React Native Web is that you can reuse your mobile application’s source code on the web. As soon as you start to rewrite logic and components, you start to reduce the amount of reuse and thus the benefit of using the same codebase is diminished. In order to maximize the amount of reuse we achieved we devised a couple of strategies to aid us in our journey.</p>
<h2 id="strategies-for-code-reuse">Strategies for Code Reuse</h2>
<p>Whilst the overall designs had been optimized for web, many of the components that appeared on the screen could be reused between web and mobile. In many cases, we required only very trivial changes to the component in order to adjust the style for web.</p>
<h3 id="branching-within-components">Branching Within Components</h3>
<p>In such cases we opted for a very simple solution of basic conditional branching within our components. For instance, to conditionally apply a style we can simply check the current operating system using <code>Platform.OS</code>:</p>
<pre><code class="lang-js">const marginStyle = {
  marginTop: Platform.OS === &quot;android&quot; ? 60 : 19,
  marginBottom: Platform.OS === &quot;android&quot; ? 60 : 0
};
</code></pre>
<p>However, rather than using ternary statements we preferred the declarative approach of <code>Platform.select</code>:</p>
<pre><code class="lang-js">const someJsx = (
  &lt;SomeComponent
    style={Platform.select({
      android: styles.androidStyle,
      ios: styles.iosStyle
    })}
  /&gt;
);
</code></pre>
<p>A limitation that we found with <code>Platform.select</code> is that it is mainly intended for switching behaviors between iOS and Android. So, in cases where we want to branch on web and mobile but not discriminate between iOS and Android, we found ourselves having to repeat ourselves:</p>
<pre><code class="lang-js">const style = Platform.select({
  android: styles.mobileStyle,
  ios: styles.mobileStyle,
  web: styles.webStyle
});
</code></pre>
<p>To solve this problem, we implemented our own variation of <code>Platform.select</code>, that we call <code>selectOnPlatform</code>. This allows us to discriminate between mobile and web but easily fallback to different Android and iOS behavior too if you wish.</p>
<pre><code class="lang-js">// Mobile and web only
const style = selectOnPlatform({
  mobile: styles.mobileStyle,
  web: styles.webStyle
});

// Alternatively, analogous to Platform.select
const style = selectOnPlatform({
  android: styles.androidStyle,
  ios: styles.iosStyle,
  web: styles.webStyle
});
</code></pre>
<p>The full implementation of <code>selectOnPlatform</code> <a href="https://gist.github.com/jdmunro/b7bfe10dac089eab50d9ca43949d7b35#file-selectonplatform-js">is available here</a>.</p>
<h3 id="component-branching">Component Branching</h3>
<p>Sometimes a component would require many changes to work correctly on each platform, and so a different strategy was required.</p>
<p>Instead of adding many conditionals into a single component file, we opted to branch at the component level using platform-specific files. We came up with a simple heuristic to decide when to split into platform-specific components: if a component required more than 2-3 branches then it was typically a viable candidate for refactoring into platform-specific files.</p>
<p>Creating platform-specific components is simple: if you have a component called <code>MyComponent.js</code>, you can create a new version of it (ideally with the same public interface) called <code>MyComponent.web.js</code>. Then make sure you have the correct resolve configuration in your Webpack config:</p>
<pre><code class="lang-js">module.exports = {
  // ...
  resolve: {
    // ...
    // Prefer .web.js over .js files
    extensions: [&quot;.web.js&quot;, &quot;.js&quot;]
  }
};
</code></pre>
<p>The web version of your application will now resolve to <code>MyComponent.web.js</code> and the mobile version will not even be included in the compiled web bundle.</p>
<p>This technique was invaluable for solving some of the hierarchical differences in the way components are composed between web and mobile: on both platforms the app features a <code>FeedbackView</code> which displays feedback to the user based on whether they answered the question correctly or not. On mobile this is a ‘floating view’ that appears over the top of the activity, whereas on web this appears in the bottom bar.</p>
<p>
  <figure>
    <img
      src="https://i.imgur.com/QadTlSG.png"
      alt="Practice Component Hierarchy on Web"
    />
    <figcaption style="text-align:center;">Practice Component Hierarchy on Web 🖥️</figcaption>
  </figure>
</p>
<p>In both cases, the root component here is a <code>LearningScreen</code>. This component is the same for both web and mobile. However, several of the sub-components you see have platform-specific implementations: <code>ExerciseTopBar</code>, <code>ExerciseBottomBar</code>, <code>ExerciseBody</code> and <code>FeedbackView</code>. These have been branched due to major differences in layout between the web and mobile versions, but many of the components they use internally are still shared 1:1 across platforms.</p>
<p>
  <figure>
    <img
      src="https://i.imgur.com/XFxMUzz.png"
      alt="Practice Component Hierarchy on Mobile"
      style="max-width:250px; max-height:250px; width:auto; height:auto;"
    />
    <figcaption style="text-align:center;">Practice Component Hierarchy on Mobile 📱</figcaption>
  </figure>
</p>
<p>This also allows us to solve the differences in view hierarchy: the web version of <code>FeedbackView</code> is rendered inside <code>ExerciseBottomBar</code>, whereas on the mobile version it’s rendered inside <code>Activity</code>.</p>
<h3 id="connecting-it-all-together">Connecting it all together</h3>
<p>Sometimes we found it beneficial to branch at the screen level, for situations where the differences between a screen layout were large, or multiple screens shared the same props and bound action creators. However, there is still opportunities for code reuse at this level: in our app we use Redux as our state container. Screens are connected to the redux store using react-redux and connect calls. Connect calls are curried and can be partially applied: we found this useful for sharing selector and bound action creators between screens that had a different layout but the same or very similar functionality.</p>
<p>Here’s an example where we partially apply the <code>connect</code> call:</p>
<pre><code class="lang-js">// connectAfterWorkoutScreen.js
export default connect(
  mapStateToProps, // Map state to props for both screens
  mapDispatchToProps // Map dispatch to props for both screens
);
</code></pre>
<p>Then we can just import this and use it as needed, binding to each component as necessary:</p>
<pre><code class="lang-js">// AfterWorkoutScreen.web.js
// AfterWorkoutScreen.js
import connectAfterWorkoutScreen from &#39;./connectAfterWorkoutScreen&#39;

class AfterWorkoutScreen extends React.PureComponent {
  // ...
}

// Re-use the connect call
default default connectAfterWorkoutScreen(AfterWorkoutScreen)
</code></pre>
<h3 id="go-with-the-flow">Go with the Flow</h3>
<p>Another technique we found useful when paired with the component branching above was to share flow-types between the components. Ideally, platform-specific components will still have the same public interface (exposed via it’s props) so that other components can consume them in a platform-agnostic way, without needing to know which implementation is being used.</p>
<p>Rather than duplicating the types between the components, we found it useful to import the types from the original mobile component:</p>
<pre><code class="lang-js">// ExerciseTopBar.web.js

// Import the props from the mobile implementation
// The actual JS will not be included in the web bundle
import type { Props } from &quot;app/components/ExerciseTopBar.js&quot;;
</code></pre>
<p>This allows us to easily share the types between the different components without any duplication.</p>
<h2 id="next-steps">Next Steps</h2>
<p>The combination of the above techniques allowed us to do most of the work to port our mobile application to web. However, we still had some way to go before we could consider our app to be production-ready: during the port we encountered some functional differences between mobile and web and the output JS bundle size was enormous - far too big to ship to the browser.</p>
<p><em>Stay tuned for part 3 to see how we brought everything together into the final shipped version! Interested in working with DataCamp? <a href="https://www.datacamp.com/careers/">Check out our careers page!</a></em></p>


https://www.datacamp.com/community/tech/porting-practice-to-web-part2

Learn how DataCamp ported their mobile application to the web using react-native-web

Porting Practice to Web: react-native-web in Production

<p>
  <em
    >This article is part of a short series in which DataCamp’s Practice &amp;
    Mobile Team describe the process of porting a mobile application to the web.
    This first part covers the initial goals and motivation for the project.
    Stay tuned for parts 2 and 3 which go more in-depth on the technical aspects
    of the project.</em
  >
</p>
<p>
  Keen DataCampers may have noticed that we recently launched a new version of
  DataCamp Practice for Web. Beyond the slick new visual theme, many of the
  changes were technical improvements behind the scenes.
</p>
<p>
  <figure>
    <img
      src="https://imgur.com/SWbtyx4.png"
      alt="Screenshot of New Practice Mode"
    />
    <figcaption style="text-align:center;">New practice mode 🚀</figcaption>
  </figure>
</p>
<p>
  The technical improvements are designed to help us iterate and innovate more
  quickly and ultimately deliver more value to users. The most exciting part is
  that it’s actually a near-direct port of the practice mode that features in
  our own mobile app: DataCamp’s practice mode now shares the same codebase for
  both mobile and web!
</p>
<h2 id="are-you-mad-">Are you mad?</h2>
<p>
  Whilst DataCamp already had a practice mode for web, it was in 'maintenance mode' (receiving bug fixes and patches) but no new features.
  Meanwhile, we developed and launched a new version of practice for
  <a href="https://www.datacamp.com/mobile">DataCamp for Mobile</a>, which
  focuses on learning on-the-go.
</p>
<p>
  <figure>
    <img
      src="https://i.imgur.com/DjsTT6o.png"
      alt="Screenshot of Legacy Practice Mode"
    />
    <figcaption style="text-align:center;">The legacy practice mode</figcaption>
  </figure>
</p>
<p>
  Practice is a core part (literally in the middle!) of DataCamp’s Learn -&gt;
  Practice -&gt; Apply approach to teaching data science. Recently, it became a
  strategic goal of the Mobile Team (now Practice &amp; Mobile Team) to take
  ownership of Practice in general at DataCamp in order to drive innovation and
  bring further value to our users.
</p>
<p>
  Now with 2 separate application to maintain, the question soon arose of how
  our team could easily add new features to both web and mobile without
  duplicating our efforts (and bugs!) across 2 distinct codebases.
</p>
<p>
  With limited engineering capacity in our team (just 2 engineers), it soon
  became clear that maintaining a single codebase was the best solution to our
  problem and we soon set about dreaming up a strategy to turn this idea into a
  reality.
</p>
<h2 id="bringing-a-mobile-app-to-the-browser">
  Bringing a mobile app to the browser
</h2>
<p>
  At DataCamp we are heavily invested in the JavaScript ecosystem: many of our
  applications are written in JS for both the frontend and backend.
</p>
<p>
  Our mobile app is no exception, we rely on many modern JS tools and
  technologies to build it. The backend is a NodeJS application which exposes an
  API via GraphQL and the frontend is the app itself which is written in React
  Native. Needless to say DataCamp are big React fans!
</p>
<p>
  The legacy practice for web application was also written in JS, complete with
  its own backend. This posed a problem: our ideal solution would not involve
  maintaining 2 separate backends.
</p>
<p>
  <figure>
    <img
      src="https://i.imgur.com/zZiomM0.png"
      alt="Fragmented App Architecture"
    />
    <figcaption style="text-align:center;">
      A fragmented app architecture
    </figcaption>
  </figure>
</p>
<p>
  Our recently developed mobile backend is capable of serving up practice
  content, but this would involve re-writing the legacy app’s frontend to use
  the existing backend. This would leave us with 1 backend but 2 distinct
  frontends. Better, but not ideal! There are also significant differences in
  how each app interacts with its backend which would have presented some
  difficult technical challenges: the legacy app is ‘online first’ whereas the
  mobile app is ‘offline first’ and is designed to interact with its content
  offline.
</p>
<p>
  Instead of maintaining 2 frontends, wouldn’t it be ideal if we could reuse our
  mobile frontend on the web in conjunction with our existing mobile backend?
  This would allow us to take advantage of all the existing code we have and
  also re-use the backend that was currently serving the mobile app. A large
  obstacle that stood in our way: how can we get the frontend code running in a
  browser?
</p>
<p>
  We previously mentioned that our mobile app is written in React Native. This
  is a powerful technology that allows developers to write native mobile apps
  using JS. Due to being JS and React-based, the amount of resistance in reusing
  the code in a browser environment is lower than it might seem at first.
</p>
<p>
  Fortunately, there are JS community efforts to bring React Native apps to the
  browser. One of the front-runners is
  <a href="https://github.com/necolas/react-native-web">react-native-web</a>: a
  port of React Native that allows you to target the DOM instead of mobile
  devices using the same code. In theory, this would allow us to reuse our
  existing codebase with minimal modification.
</p>
<p>
  <figure>
    <img src="https://i.imgur.com/afxWgXJ.png" alt="Unified App Architecture" />
    <figcaption style="text-align:center;">
      A unified app architecture
    </figcaption>
  </figure>
</p>
<p>
  We set about working on a proof-of-concept and fell into a pit of success. We
  were able to get a super rough version of the mobile app in a browser running
  very quickly:
</p>
<p>
  <figure>
    <img
      src="https://i.imgur.com/SUjiRo0.png"
      alt="An Early Proof of Concept"
    />
    <figcaption style="text-align:center;">
      Early proof of concept - what can we improve 🤔
    </figcaption>
  </figure>
</p>
<p>
  Whilst it was possible to get a proof-of-concept running quickly, the gulf
  between a scrappy proof-of-concept and a full-blown production app is quite
  large! Beyond the user interface, we had to reconsider several functional
  design aspects and also rework some of the underlying technical systems in
  order to optimise the user experience. The process of perfecting our port took
  a couple of months with 2 engineers and we learned a huge amount during this
  journey.
</p>
<p>
  A separate article will explain some of the ins-and-outs of using
  react-native-web in production.
</p>
<h2 id="reflection-and-the-future">Reflection and the future</h2>
<p>
  Overall, we consider our port of mobile practice to web to have been a
  complete success. Our early user feedback and analytics demonstrate that it is
  performing at least as well as the previous web version which was our initial
  goal. From here on, we can now rapidly innovate on our codebase and bring
  innovation to web and mobile simultaneously.
</p>
<p>
  <figure>
    <img src="https://imgur.com/B8nYx3g.png" alt="Practice Completed!" />
    <figcaption style="text-align:center;">Practice completed! 🎉</figcaption>
  </figure>
</p>
<p>
  We estimate that we were able to reuse 90% of our mobile components on the web
  and a similar amount of the business logic through our action creators,
  reducers and networking layer. In fact, the level of reuse was so high that
  early versions of the port had entire features of the mobile app accessible by
  the user, such as the dashboard and mobile Learn experience that we had no
  intention of bringing to the web.
</p>
<p>
  The benefits of having a shared codebase go beyond basic code reuse. Part of
  the porting process involved adapting the user interface of practice to make
  better use of the horizontal screen space provided by modern widescreen
  desktops. This is quite a different aspect ratio to mobile phone screens which
  are optimised for vertical content and scrolling. However, tablets such as the
  iPad are much less focused on vertical content and so we also have the option
  in future of deciding which interface to use based on a device’s screen
  dimensions, rather than just on platform alone.
</p>
<p>
  We look forward to bringing out new features and improvements for DataCamp
  practice for both mobile and web over the next weeks and months!
</p>
<p>
  <em
    >Stay tuned for parts 2 and 3 which go more in-depth on the technical
    aspects of the project. Interested in working with DataCamp?
    <a href="https://www.datacamp.com/careers/"
      >Check out our careers page!</a
    ></em
  >
</p>


https://www.datacamp.com/community/tech/porting-practice-to-web-part1

Learn how DataCamp ported their mobile application to the web and achieved high levels of code reuse.

community

datacamp

technical

News (7)

Jupyter Notebook in Visual Studio Code

Python XML with ElementTree: Beginner's Guide

Tutorials (0)

Cheat Sheets (0)

Open Courses (0)

Podcast (1)

Building Data Science Teams (with Drew Conway)

Blog Posts (7)

How to Learn SQL

Tech Thoughts (10)

Porting Practice to Web: react-native-web in Production