<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Development on Jaehyeon Kim</title><link>https://jaehyeon.me/categories/development/</link><description>Recent content in Development on Jaehyeon Kim</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Copyright © 2023-2026 Jaehyeon Kim. All Rights Reserved.</copyright><lastBuildDate>Wed, 19 Nov 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://jaehyeon.me/categories/development/index.xml" rel="self" type="application/rss+xml"/><item><title>Guide to Building Integrated Web Applications with FastAPI and NiceGUI</title><link>https://jaehyeon.me/blog/2025-11-19-fastapi-nicegui-template/</link><pubDate>Wed, 19 Nov 2025 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2025-11-19-fastapi-nicegui-template/</guid><description>&lt;p>The standard architecture for modern web applications involves a decoupled frontend, typically built with a JavaScript framework, and a backend API. This pattern is powerful but introduces complexity in managing two separate codebases, development environments, and the API contract between them.&lt;/p>
&lt;p>This article explores an alternative approach: an integrated architecture where the backend API and the frontend UI are served from a single, cohesive Python application.&lt;/p></description><enclosure url="https://jaehyeon.me/blog/2025-11-19-fastapi-nicegui-template/featured.gif" length="2611548" type="image/gif"/></item><item><title>Realtime Dashboard with FastAPI, Streamlit and Next.js - Part 3 Next.js Dashboard</title><link>https://jaehyeon.me/blog/2025-03-04-realtime-dashboard-3/</link><pubDate>Tue, 04 Mar 2025 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2025-03-04-realtime-dashboard-3/</guid><description><![CDATA[<p>In this post, we build a real-time monitoring dashboard using <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer">Next.js<i class="fas fa-external-link-square-alt ms-1"></i></a>, a React framework that supports server-side rendering, static site generation, and full-stack capabilities with built-in performance optimizations. Similar to the <em>Streamlit</em> app we developed in <a href="/blog/2025-02-25-realtime-dashboard-2">Part 2</a>, this dashboard connects to the WebSocket server from <a href="/blog/2025-02-18-realtime-dashboard-1">Part 1</a> to continuously fetch and visualize key metrics such as <strong>order counts</strong>, <strong>sales data</strong>, and <strong>revenue by traffic source and country</strong>. With interactive bar charts and dynamic metrics, users can monitor sales trends and other critical business KPIs in real-time.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2025-03-04-realtime-dashboard-3/featured.gif" length="323475" type="image/gif"/></item><item><title>Realtime Dashboard with FastAPI, Streamlit and Next.js - Part 2 Streamlit Dashboard</title><link>https://jaehyeon.me/blog/2025-02-25-realtime-dashboard-2/</link><pubDate>Tue, 25 Feb 2025 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2025-02-25-realtime-dashboard-2/</guid><description><![CDATA[<p>In this post, we develop a real-time monitoring dashboard using <a href="https://streamlit.io/" target="_blank" rel="noopener noreferrer">Streamlit<i class="fas fa-external-link-square-alt ms-1"></i></a>, an open-source Python framework that allows data scientists and AI/ML engineers to create interactive data apps. The app connects to the WebSocket server we developed in <a href="/blog/2025-02-18-realtime-dashboard-1">Part 1</a> and continuously fetches data to visualize key metrics such as <strong>order counts</strong>, <strong>sales data</strong>, and <strong>revenue by traffic source and country</strong>. With interactive bar charts and dynamic metrics, users can monitor sales trends and other important business KPIs in real-time.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2025-02-25-realtime-dashboard-2/featured.gif" length="417216" type="image/gif"/></item><item><title>Realtime Dashboard with FastAPI, Streamlit and Next.js - Part 1 Data Producer</title><link>https://jaehyeon.me/blog/2025-02-18-realtime-dashboard-1/</link><pubDate>Tue, 18 Feb 2025 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2025-02-18-realtime-dashboard-1/</guid><description><![CDATA[<p>In this series, we develop real-time monitoring dashboard applications. A data generating app is created with Python, and it ingests the <a href="https://console.cloud.google.com/marketplace/product/bigquery-public-data/thelook-ecommerce" target="_blank" rel="noopener noreferrer">theLook eCommerce<i class="fas fa-external-link-square-alt ms-1"></i></a> data continuously into a PostgreSQL database. A WebSocket server, built by <a href="https://fastapi.tiangolo.com/" target="_blank" rel="noopener noreferrer">FastAPI<i class="fas fa-external-link-square-alt ms-1"></i></a>, periodically queries the data to serve its clients. The monitoring dashboards will be developed using <a href="https://streamlit.io/" target="_blank" rel="noopener noreferrer">Streamlit<i class="fas fa-external-link-square-alt ms-1"></i></a> and <a href="https://nextjs.org/" target="_blank" rel="noopener noreferrer">Next.js<i class="fas fa-external-link-square-alt ms-1"></i></a>, with <a href="https://echarts.apache.org/en/index.html" target="_blank" rel="noopener noreferrer">Apache ECharts<i class="fas fa-external-link-square-alt ms-1"></i></a> for visualization. In this post, we walk through the data generation app and backend API, while the monitoring dashboards will be discussed in later posts.</p>]]></description><enclosure url="https://jaehyeon.me/blog/2025-02-18-realtime-dashboard-1/featured.gif" length="1207440" type="image/gif"/></item><item><title>Setup Local Development Environment for Apache Flink and Spark Using EMR Container Images</title><link>https://jaehyeon.me/blog/2023-12-07-flink-spark-local-dev/</link><pubDate>Thu, 07 Dec 2023 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2023-12-07-flink-spark-local-dev/</guid><description>[UPDATE 2025-10-01]
Bitnami&amp;rsquo;s public Docker images have been moved to the Bitnami Legacy repository. To ensure continued access and compatibility, please update your Docker image references accordingly.
For example:
bitnami/kafka:2.8.1 → bitnamilegacy/kafka:2.8.1 bitnami/zookeeper:3.7.0 → bitnamilegacy/zookeeper:3.7.0 bitnami/python:3.9.0 → bitnamilegacy/python:3.9.0 Apache Flink became generally available for Amazon EMR on EKS from the EMR 6.15.0 releases, and we are able to pull the Flink (as well as Spark) container images from the ECR Public Gallery.</description><enclosure url="https://jaehyeon.me/blog/2023-12-07-flink-spark-local-dev/featured.png" length="133053" type="image/png"/></item><item><title>Serverless Application Model (SAM) for Data Professionals</title><link>https://jaehyeon.me/blog/2022-07-18-sam-for-data-professionals/</link><pubDate>Mon, 18 Jul 2022 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2022-07-18-sam-for-data-professionals/</guid><description>AWS Lambda provides serverless computing capabilities, and it can be used for performing validation or light processing/transformation of data. Moreover, with its integration with more than 140 AWS services, it facilitates building complex systems employing event-driven architectures. There are many ways to build serverless applications and one of the most efficient ways is using specialised frameworks such as the AWS Serverless Application Model (SAM) and Serverless Framework. In this post, I’ll demonstrate how to build a serverless data processing application using SAM.</description><enclosure url="https://jaehyeon.me/blog/2022-07-18-sam-for-data-professionals/featured.png" length="22838" type="image/png"/></item><item><title>Simplify Your Development on AWS with Terraform</title><link>https://jaehyeon.me/blog/2022-02-06-dev-infra-terraform/</link><pubDate>Sun, 06 Feb 2022 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2022-02-06-dev-infra-terraform/</guid><description>When I wrote my data lake demo series (part 1, part 2 and part 3) recently, I used an Aurora PostgreSQL, MSK and EMR cluster. All of them were deployed to private subnets and dedicated infrastructure was created using CloudFormation. Using the infrastructure as code (IaC) tool helped a lot, but it resulted in creating 7 CloudFormation stacks, which was a bit harder to manage in the end. Then I looked into how to simplify building infrastructure and managing resources on AWS and decided to use Terraform instead.</description><enclosure url="https://jaehyeon.me/blog/2022-02-06-dev-infra-terraform/featured.png" length="46253" type="image/png"/></item><item><title>Yet another serverless solution for invoking AWS Lambda at a sub-minute frequency</title><link>https://jaehyeon.me/blog/2021-10-13-lambda-schedule/</link><pubDate>Wed, 13 Oct 2021 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2021-10-13-lambda-schedule/</guid><description>Triggering a Lambda function by an EventBridge Events rule can be used as a _serverless _replacement of cron job. The highest frequency of it is one invocation per minute so that it cannot be used directly if you need to schedule a Lambda function more frequently. For example, it may be refreshing an application with real time metrics from an Amazon Connect instance where some metrics are updated every 15 seconds.</description><enclosure url="https://jaehyeon.me/blog/2021-10-13-lambda-schedule/featured.png" length="46921" type="image/png"/></item><item><title>Adding Authorization to a Graphql API</title><link>https://jaehyeon.me/blog/2021-07-20-graphql-api-authorization/</link><pubDate>Tue, 20 Jul 2021 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2021-07-20-graphql-api-authorization/</guid><description>Authorization is the mechanism that controls who can do what on which resource in an application. Although it is a critical part of an application, there are limited resources available on how to build authorization into an app effectively. In this post, I&amp;rsquo;ll be illustrating how to set up authorization in a GraphQL API using a custom directive and Oso, an open-source authorization library. This tutorial covers the NodeJS variant of Oso, but it also supports Python and other languages.</description><enclosure url="https://jaehyeon.me/blog/2021-07-20-graphql-api-authorization/featured.png" length="52143" type="image/png"/></item><item><title>Dynamic Routing and Centralized Auth with Traefik, Python and R Example</title><link>https://jaehyeon.me/blog/2019-11-29-traefik-example/</link><pubDate>Fri, 29 Nov 2019 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2019-11-29-traefik-example/</guid><description>Ingress in Kubernetes exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. By setting rules, it routes requests to appropriate services (precisely requests are sent to individual Pods by Ingress Controller). Rules can be set up dynamically and I find it&amp;rsquo;s more efficient compared to traditional reverse proxy.
Traefik is a modern HTTP reverse proxy and load balancer and it can be used as a Kubernetes Ingress Controller.</description><enclosure url="https://jaehyeon.me/blog/2019-11-29-traefik-example/featured.png" length="139790" type="image/png"/></item><item><title>Distributed Task Queue with Python and R Example</title><link>https://jaehyeon.me/blog/2019-11-15-task-queue/</link><pubDate>Fri, 15 Nov 2019 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2019-11-15-task-queue/</guid><description>While I&amp;rsquo;m looking into Apache Airflow, a workflow management tool, I thought it would be beneficial to get some understanding of how Celery works. To do so, I built a simple web service that sends tasks to Celery workers and collects the results from them. FastAPI is used for developing the web service and Redis is used for the message broker and result backend. During the development, I thought it would be possible to implement similar functionality in R with Rserve.</description><enclosure url="https://jaehyeon.me/blog/2019-11-15-task-queue/featured.png" length="51615" type="image/png"/></item><item><title>Linux Dev Environment on Windows</title><link>https://jaehyeon.me/blog/2019-11-01-linux-on-windows/</link><pubDate>Fri, 01 Nov 2019 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2019-11-01-linux-on-windows/</guid><description>I use Linux containers a lot for development. Having Windows computers at home and work, I used to use Linux VMs on VirtualBox or VMWare Workstation. It&amp;rsquo;s not a bad option but it requires a lot of resources. Recently, after my home computer was updated, I was not able to start my hypervisor anymore. Also I didn&amp;rsquo;t like huge resource consumption of it so that I began to look for a different development environment.</description><enclosure url="https://jaehyeon.me/blog/2019-11-01-linux-on-windows/featured.png" length="187978" type="image/png"/></item><item><title>AWS Local Development with LocalStack</title><link>https://jaehyeon.me/blog/2019-07-20-aws-localstack/</link><pubDate>Sat, 20 Jul 2019 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2019-07-20-aws-localstack/</guid><description>LocalStack provides an easy-to-use test/mocking framework for developing AWS applications. In this post, I&amp;rsquo;ll demonstrate how to utilize LocalStack for development using a web service.
Specifically a simple web service built with Flask-RestPlus is used. It supports simple CRUD operations against a database table. It is set that SQS and Lambda are used for creating and updating a record. When a POST or PUT request is made, the service sends a message to a SQS queue and directly returns 204 reponse.</description><enclosure url="https://jaehyeon.me/blog/2019-07-20-aws-localstack/featured.png" length="164886" type="image/png"/></item><item><title>Cronicle Multi Server Setup</title><link>https://jaehyeon.me/blog/2019-07-19-cronicle-multi-server-setup/</link><pubDate>Fri, 19 Jul 2019 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2019-07-19-cronicle-multi-server-setup/</guid><description>Accroding to the project GitHub repository,
Cronicle is a multi-server task scheduler and runner, with a web based front-end UI. It handles both scheduled, repeating and on-demand jobs, targeting any number of slave servers, with real-time stats and live log viewer.
By default, Cronicle is configured to launch a single master server - task scheduling is controlled by the master server. For high availability, it is important that another server takes the role of master when the existing master server fails.</description><enclosure url="https://jaehyeon.me/blog/2019-07-19-cronicle-multi-server-setup/featured.png" length="64396" type="image/png"/></item><item><title>Shiny to Vue.js</title><link>https://jaehyeon.me/blog/2018-05-26-shiny-to-vue.js/</link><pubDate>Sat, 26 May 2018 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2018-05-26-shiny-to-vue.js/</guid><description>In the last post, the async feature of Shiny was discussed. Although it is a remarkable step forward to web development in R, it is not to the full extent that a Javascript application can bring. In fact, (long running) requests of a user (or session) are not impacted by those of other users (or sessions) but, for a given user, all requests are handled sequentially. On the other hand, it is not the case for a Javascript-backed app where all requests are processed asynchronously.</description><enclosure url="https://jaehyeon.me/blog/2018-05-26-shiny-to-vue.js/featured.png" length="247205" type="image/png"/></item><item><title>Async Shiny and Its Limitation</title><link>https://jaehyeon.me/blog/2018-05-19-asyn-shiny-and-its-limitation/</link><pubDate>Sat, 19 May 2018 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2018-05-19-asyn-shiny-and-its-limitation/</guid><description>A Shiny app is served by one (single-threaded blocking) process by Open Source Shiny Server. This causes a scalability issue because all requests are handled one by one in a queue. Recently the creator of Shiny introduced the promises package, which brings asynchronous programming capabilities to R. This is a remarkable step forward to web development in R.
In this post, it&amp;rsquo;ll be demonstrated how to implement the async feature of Shiny.</description><enclosure url="https://jaehyeon.me/blog/2018-05-19-asyn-shiny-and-its-limitation/featured.png" length="247205" type="image/png"/></item><item><title>API Development with R Part II</title><link>https://jaehyeon.me/blog/2017-11-19-api-development-with-r-2/</link><pubDate>Sun, 19 Nov 2017 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2017-11-19-api-development-with-r-2/</guid><description>In Part I, it is discussed how to serve an R function with plumber, Rserve and rApache. In this post, the APIs are deployed in a Docker container and, after showing example requests, their performance is compared. The rocker/r-ver:3.4 is used as the base image and each of the APIs is added to it. For simplicity, the APIs are served by Supervisor. For performance testing, Locust is used. The source of this post can be found in this GitHub repository.</description><enclosure url="https://jaehyeon.me/blog/2017-11-19-api-development-with-r-2/featured.png" length="367256" type="image/png"/></item><item><title>API Development with R Part I</title><link>https://jaehyeon.me/blog/2017-11-18-api-development-with-r-1/</link><pubDate>Sat, 18 Nov 2017 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2017-11-18-api-development-with-r-1/</guid><description>API is an effective way of distributing analysis outputs to external clients. When it comes to API development with R, however, there are not many choices. Probably development would be made with plumber, Rserve, rApache or OpenCPU if a client or bridge layer to R is not considered.
This is 2 part series in relation to API development with R. In this post, serving an R function with plumber, Rserve and rApache is discussed.</description><enclosure url="https://jaehyeon.me/blog/2017-11-18-api-development-with-r-1/featured.png" length="367256" type="image/png"/></item><item><title>Serverless Data Product POC Backend Part IV - Serving R ML Model via S3</title><link>https://jaehyeon.me/blog/2017-04-17-serverless-data-product-4/</link><pubDate>Mon, 17 Apr 2017 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2017-04-17-serverless-data-product-4/</guid><description>In the previous posts, it is discussed how to package/deploy an R model with AWS Lambda and to expose the Lambda function via Amazon API Gateway. Main benefits of serverless architecture is cost-effectiveness and being hassle-free from provisioning/managing servers. While the API returns a predicted admission status value given GRE, GPA and Rank, there is an issue if it is served within a web application: Cross-Origin Resource Sharing (CORS). This post discusses how to resolve this issue by updating API configuration and the Lambda function handler with a simple web application.</description><enclosure url="https://jaehyeon.me/blog/2017-04-17-serverless-data-product-4/featured.png" length="225463" type="image/png"/></item><item><title>Serverless Data Product POC Backend Part III - Exposing R ML Model via APIG</title><link>https://jaehyeon.me/blog/2017-04-13-serverless-data-product-3/</link><pubDate>Thu, 13 Apr 2017 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2017-04-13-serverless-data-product-3/</guid><description>In Part I of this series, R and necessary libraries/packages together with a Lambda function handler are packaged and saved to Amazon S3. Then, in Part II, the package is deployed at AWS Lambda after creating and assigning a role to the Lambda function. Although the Lambda function can be called via the Invoke API, it&amp;rsquo;ll be much more useful if the function can be called as a web service (or API).</description><enclosure url="https://jaehyeon.me/blog/2017-04-13-serverless-data-product-3/featured.png" length="173293" type="image/png"/></item><item><title>Serverless Data Product POC Backend Part II - Deploying R ML Model via Lambda</title><link>https://jaehyeon.me/blog/2017-04-11-serverless-data-product-2/</link><pubDate>Tue, 11 Apr 2017 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2017-04-11-serverless-data-product-2/</guid><description>In the previous post, serverless event-driven application development is introduced. Also how to package R, necessary libraries/packages and a Lambda function handler is discussed. No need of provisioning/managing servers is one of the key benefits of the architecture. It is also a cost-effective way of delivering a data product as functions are executed on-demand rather than in servers that run 24/7. Furthermore AWS Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month, which is available to both existing and new AWS customers indefinitely.</description><enclosure url="https://jaehyeon.me/blog/2017-04-11-serverless-data-product-2/featured.png" length="139725" type="image/png"/></item><item><title>Serverless Data Product POC Backend Part I - Packaging R ML Model for Lambda</title><link>https://jaehyeon.me/blog/2017-04-08-serverless-data-product-1/</link><pubDate>Sat, 08 Apr 2017 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2017-04-08-serverless-data-product-1/</guid><description><![CDATA[Let say you&rsquo;ve got a prediction model built in R and you&rsquo;d like to productionize it, for example, by serving it in a web application. One way is exposing the model through an API that returns the predicted result as a web service. However there are many issues. Firstly R is not a language for API development although there may be some ways - eg the plumber package. More importantly developing an API is not the end of the story as the API can&rsquo;t be served in a production system if it is not deployed/managed/upgraded/patched/&hellip; appropriately in a server or if it is not scalable, protected via authentication/authorization and so on.]]></description><enclosure url="https://jaehyeon.me/blog/2017-04-08-serverless-data-product-1/featured.png" length="139725" type="image/png"/></item><item><title>Some Thoughts on Shiny Open Source - Render Multiple Pages</title><link>https://jaehyeon.me/blog/2016-06-27-shiny-open-source-render-multiple-pages/</link><pubDate>Mon, 27 Jun 2016 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2016-06-27-shiny-open-source-render-multiple-pages/</guid><description>R Shiny applications are served as a single page application and it is not built to render multiple pages. There are benefits of rendering multiple pages such as code management and implement authentication. In this page, we discuss how to implement multi-page rendering in a Shiny app.
As indicated above, Shiny is not designed to render multiple pages and, in general, the UI is rendered on the fly as defined in ui.</description></item><item><title>Some Thoughts on Shiny Open Source - Internal Load Balancing</title><link>https://jaehyeon.me/blog/2016-05-23-shiny-open-source-internal-load-balancing/</link><pubDate>Mon, 23 May 2016 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2016-05-23-shiny-open-source-internal-load-balancing/</guid><description>Shiny is an interesting web framework that helps create a web application quickly. If it targets a large number of users, however, there are several limitations and it is so true when the open source version of Shiny is in use. It would be possible to tackle down some of the limitations with the enterprise version but it is not easy to see enough examples of Shiny applications in production environment.</description></item><item><title>Asynchronous Processing Using Job Queue</title><link>https://jaehyeon.me/blog/2016-05-12-asynchronous-processing-using-job-queue/</link><pubDate>Thu, 12 May 2016 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2016-05-12-asynchronous-processing-using-job-queue/</guid><description>In this post, a way to overcome one of R&amp;rsquo;s limitations (lack of multi-threading) is discussed by job queuing using the jobqueue package - a generic asynchronous job queue implementation for R. See the package description below.
The jobqueue package is meant to provide an easy-to-use interface that allows to queue computations for background evaluation while the calling R session remains responsive. It is based on a 1-node socket cluster from the parallel package.</description></item><item><title>Quick Test to Wrap Python in R</title><link>https://jaehyeon.me/blog/2015-11-21-quick-test-to-wrap-python-in-r/</link><pubDate>Sat, 21 Nov 2015 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2015-11-21-quick-test-to-wrap-python-in-r/</guid><description>As mentioned in an earlier post, things that are not easy in R can be relatively simple in other languages. Another example would be connecting to Amazon Web Services. In relation to s3, although there are a number of existing packages, many of them seem to be deprecated, premature or platform-dependent. (I consider the cloudyr project looks promising though.)
If there isn&amp;rsquo;t a comprehensive R-way of doing something yet, it may be necessary to create it from scratch.</description></item><item><title>Some Thoughts on Python for R Users</title><link>https://jaehyeon.me/blog/2015-08-09-some-thoughts-on-python-for-r-users/</link><pubDate>Sun, 09 Aug 2015 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2015-08-09-some-thoughts-on-python-for-r-users/</guid><description>There seem to be growing interest in Python in the R cummunity. While there can be a range of opinions about using R over Python (or vice versa) for exploratory data analysis, fitting statistical/machine learning algorithms and so on, I consider one of the strongest attractions of using Python comes from the fact that Python is a general purpose programming language. As more developers are involved in, it can provide a way to get jobs done easily, which can be tricky in R.</description></item><item><title>Some Thoughts on Python</title><link>https://jaehyeon.me/blog/2015-08-08-some-thoughts-on-python/</link><pubDate>Sat, 08 Aug 2015 00:00:00 +0000</pubDate><guid>https://jaehyeon.me/blog/2015-08-08-some-thoughts-on-python/</guid><description>When I bagan to teach myself C# 3 years ago, I only had some experience in interactive analysis tools such as MATLAB and R - I didn&amp;rsquo;t consider R as a programming language at that time. The general purpose programming language shares some common features (data type, loop, if&amp;hellip;) but it is rather different in the way how code is written/organized, which is object oriented. Therefore, while it was not a problem to grap the common features, it took quite some time to understand and keep my code in an object oriented way.</description></item></channel></rss>