Marko Petrović

Java Iterable Interface: Iterator, ListIterator, and Spliterator

Usman Malik

Python for NLP: Movie Sentiment Analysis using Deep Learning in Keras

<h2 id="introduction">Introduction</h2>
In software development, we are constantly building solutions for end-users that solve a particular problem or ease/automate a certain process. Therefore, designing and building the software is not the only part of the process, as we have to make the software available to the intended users.
For web-based applications, deployment is a very important aspect and part of the process since the application not only needs to work, but also needs to work for many users concurrently and be highly available.
Some of the deployment options that are available to us include buying our own server hardware and deploying our applications or renting server space in other companies. This comes at a cost not only of the resources needed to acquire them, but also the maintenance costs and personnel to monitor the server resources.
What if we could make our application available without having to worry about provisioning servers or maintaining them? Our agility and delivery would be greatly enhanced.
We can achieve this through a serverless computing platform such as <a rel="nofollow" target="_blank" href="https://aws.amazon.com/lambda/features/">AWS Lambda</a>, which is made available by <a rel="nofollow" target="_blank" href="https://aws.amazon.com/">Amazon Web Services</a>.
<h2 id="whatisserverlesscomputing">What is Serverless Computing?</h2>
Cloud providers offer different solutions to deploying and running applications, one of them being serverless computing. In this architecture, the cloud provider hosts your applications and takes on the responsibilities of server management in terms of software and hardware. Think of it as Infrastructure as a Service (IaaS).
The cloud provider handles scaling, availability, server maintenance, and configuration among other things so that as the developers, our focus is entirely on our code. This, in turn, reduces the overhead required to make our applications run and available to our end users.
Serverless computing has its advantages, but it also poses some drawbacks such as the developer is limited to the options or tools that the provider uses for purposes such as logging, tracing, and monitoring and the developer cannot use their own tools. Also, as a developer, you are tied to the availability of the provider, if they experience issues or outages, then our application is also affected.
AWS is a leading cloud provider that offers serverless computing through AWS Lambda. This is a serverless compute runtime that allows developers to run their code in response to certain events from users, such as making a request or uploading files into an <a rel="nofollow" target="_blank" href="https://aws.amazon.com/s3/">S3 bucket</a>.
This service also allows us to only pay for the computing resources that we utilize rather than a blanket cost for the services. This happens through a Lambda function that scales to match the scale and is independent of the underlying infrastructure.
<h2 id="whatischalice">What is Chalice?</h2>
<a rel="nofollow" target="_blank" href="https://github.com/aws/chalice">Chalice</a> is a microframework for building and quickly deploying serverless applications in Python to AWS Lambda functions. Chalice not only helps us create Python applications but also quickly deploy them by providing a command-line tool for creating, managing, and deploying our application.
Chalice also provides integration functionality to other Amazon services such as Amazon API Gateway, Amazon Simple Storage Service(S3), and Simple Queue Service (SQS), among others. We can create RESTful APIs, tasks that run on a certain schedule or integrate to the S3 bucket for storage.
<h2 id="setup">Setup</h2>
<h3 id="awssetup">AWS Setup</h3>
To get started with Chalice, we need to have an AWS account set up to interact with and deploy our code to. This can be achieved through the <a rel="nofollow" target="_blank" href="https://aws.amazon.com/">AWS homepage</a> where we can sign up or log in to an existing AWS account. AWS requires that we not only offer our details but also our billing details, but for this demonstration we will be using the <a rel="nofollow" target="_blank" href="https://aws.amazon.com/free/">AWS Free Tier</a> for testing and development purposes, for which we will not be billed.
Once our account is set up, under our profile dropdown, there is a section called &quot;My Security Credentials&quot;. Here we will be able to create credentials that will be used when interacting with the AWS console. These credentials will be also used by the Amazon CLI tool.
Amazon also offers a CLI tool that we can use to interact with our AWS services using commands in our terminal. It is available for Mac, Linux and Windows platforms and requires Python 2.6+ or Python 3.3 or later versions. We can install it by running the following pip command:
<pre><code class="hljs">$ pip install awscli
</code></pre>
Once set up, we can test the CLI tool by running:
<pre><code class="hljs">$ aws --version
</code></pre>
More details about the CLI tool and installation on other platforms can be found <a rel="nofollow" target="_blank" href="https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html">here</a>.
With the AWS CLI tool setup, we will use the credentials, i.e, secret key and access ID, that we generated earlier to configure our CLI tool by running:
<pre><code class="hljs">$ aws configure
</code></pre>
We will get a prompt to fill in our <code>Access Key ID</code>, <code>Secret Access Key</code> and default regions and output formats. The last two are optional but we will need the access key and secret that we obtained from the AWS console dashboard.
You can also configure different credentials for different users on AWS. More on that and other details can be found <a rel="nofollow" target="_blank" href="https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html">here</a>.
<h3 id="projectsetup">Project Setup</h3>
For this demo project, we will be building a Python application and it is good practice to work within a virtual environment to keep our project environment abstracted from the system’s Python environment. For this purpose, we will utilize the <code>virtualenv</code> tool to create a virtual environment within which we will work.
In case the <code>virtualenv</code> tool is not yet installed, we can install it by simply running:
<pre><code class="hljs">$ pip install virtualenv
</code></pre>
More information about the <code>virtualenv</code> tool can be found <a rel="nofollow" target="_blank" href="https://virtualenv.pypa.io/en/latest/">here</a>.
With <code>virtualenv</code> installed, let us head over to our working directory and create an environment by running the following command:
<pre><code class="hljs">$ virtualenv --python=python3 venv-chalice
</code></pre>
We will activate our environment by running:
<pre><code class="hljs">$ source venv-chalice/bin/activate
</code></pre>
Our environment is now set up, and we can now install Chalice and verify the installation by running the following commands:
<pre><code class="hljs">$ pip install chalice
$ chalice --help
</code></pre>
The second command here is simply used to verify the installation of Chalice.
<h2 id="implementation">Implementation</h2>
We now have an AWS account, the AWS CLI tool installed, the environment setup, and Chalice installed. We can now use Chalice to create our simple RESTful API as follows:
<pre><code class="hljs">$ chalice new-project demoapp
</code></pre>
This command creates a simple Chalice project within a folder that is of the following structure:
<pre><code class="hljs">$ tree demoapp
demoapp
├── app.py
└── requirements.txt
</code></pre>
Any other requirements that our Chalice app will require to run while deployed on AWS Lambda will go into the <code>requirements.txt</code> file within the <code>demoapp</code> folder, and our new functionality will mainly reside in the <code>app.py</code> file. We can create other files and import them into the <code>app.py</code> file, which is our main project file.
For our simple API, we will create an API that returns a list of a user’s public GitHub repositories, the languages used in each, and the number of stars that repository has. This information is publicly available on the GitHub API, therefore we will not need credentials to interact with the API. We will create a function that receives a username and returns the details we require. If the username provided does not exist, then we will receive an empty response payload.
Let us create the <code>github_repos</code> function that will be responsible for the GitHub API interaction:
<pre><code class="hljs">import requests

def github_repos(username):
 # Final list to contain our repository objects
 formatted_repos = []

 if username:
 # Format the url by inserting the passed username
 url = &quot;https://api.github.com/users/{}/repos&quot;.format(username)

 r = requests.get(url)

 # Get the JSON containing the list of repositories
 list_of_repos = r.json()

 for repo in list_of_repos:
 repo_object = {
 &quot;name&quot;: repo[&quot;name&quot;],
 &quot;stars&quot;: repo[&quot;watchers&quot;],
 &quot;language&quot;: repo[&quot;language&quot;],
 }

 formatted_repos.append(repo_object)

 return formatted_repos
</code></pre>
The function <code>github_repos</code> receives a username and plugs it into the GitHub API URL before making the request. The response received has a lot of information that we do not need for now, so we extract the details of a repository that we need, create a new object and add it to the list of <code>formatted_repos</code> that we will send back to the user via the Chalice app.
Let us run a few local tests for our function first and this is the output:
<img src="https://stackabuse.s3.amazonaws.com/media/serverless-python-application-development-with-aws-chalice-1.png" alt="local testing output">
The function is now ready to be integrated into our Chalice app on the <code>app.py</code> file, and this is the final version of our app:
<pre><code class="hljs">import requests
from chalice import Chalice

def github_repos(username):
 # Function implementation above

app = Chalice(app_name=&#x27;demoapp&#x27;)

@app.route(&#x27;/&#x27;)
def index():
 return {&#x27;hello&#x27;: &#x27;world&#x27;}

# Create our new route to handle github repos functionality
@app.route(&#x27;/user/{username}&#x27;)
def github(username):
 return {&quot;repos&quot;: github_repos(username)}
</code></pre>
Our application is now ready to be consumed by users, let us now deploy it to AWS Lambda.
<h2 id="deployingourapp">Deploying our App</h2>
Deploying a Chalice application to AWS Lambda is as simple as running the following command in our working directory:
<pre><code class="hljs">$ chalice deploy
</code></pre>
Chalice will handle the deployment process for us and return a link with which we can interact with the RESTful API we have just created:
<img src="https://stackabuse.s3.amazonaws.com/media/serverless-python-application-development-with-aws-chalice-2.png" alt="chalice deploy output">
To test our API, we can use <a rel="nofollow" target="_blank" href="https://www.getpostman.com/">Postman</a>, a web browser, or any other API interaction tool to make requests to the <code>/user/&lt;github-username&gt;</code> endpoint on the &quot;REST API URL&quot; from the screen-shot above. I passed in my GitHub username and this was the output:
<img src="https://stackabuse.s3.amazonaws.com/media/serverless-python-application-development-with-aws-chalice-3.png" alt="postman response">
If we make any changes to our code, we just run the <code>chalice deploy</code> command again and Chalice will redeploy our application with the changes we have just made.
When we head over to the AWS Console and click on the &quot;Functions&quot; section in the collapsible sidebar on the left side, we can see the Lambda function that is currently running our application:
<img src="https://stackabuse.s3.amazonaws.com/media/serverless-python-application-development-with-aws-chalice-4.png" alt="lambda on aws console">
When we click on our function, we get more details about it such as the current configuration, environment variables set for our application, execution roles, and memory configuration.
AWS also gives us monitoring options such as event logs and metrics through <a rel="nofollow" target="_blank" href="https://aws.amazon.com/cloudwatch/">CloudWatch</a> which is a monitoring and management service offered by AWS.
This is the view of the monitoring dashboard for our application:
<img src="https://stackabuse.s3.amazonaws.com/media/serverless-python-application-development-with-aws-chalice-5.png" alt="cloudwatch monitoring">
We get statistics on the number of invocations by users, durations of requests served by our API, the success and error rates, among other things.
We even get a view of the individual requests in the same dashboard, though this is not visible in the screenshot above. There’s so much that AWS does for us out of the box, making our deployment experience short and straight to the point. We do not have to worry about maintaining our own server or implementing our own methods of monitoring and logging as AWS has us covered for this.
This is the serverless experience.
<h2 id="summary">Summary</h2>
In this article, we have created a serverless Python API using the Chalice microframework and deployed it on AWS Lambda. The AWS CLI, alongside the Chalice CLI tools, has helped us bootstrap our project quickly and we deployed it to AWS Lambda using just one single command.
Ours is a serverless application since we did not have to handle any server provision or maintenance on our side. We just wrote the code and let AWS handle the rest for us, including deployment, scaling, and monitoring of our application. The time taken to make our application available has decreased significantly, even though we are still reliant on AWS for other aspects such as monitoring our application.
The source code for this project is available <a rel="nofollow" target="_blank" href="https://github.com/ro6ley/aws-chalice-demo">here on GitHub</a>.

Robley Gori

Serverless Python Application Development with AWS Chalice

Muhammad Junaid Khalid

Creating Python GUI Applications with wxPython

<h2 id="introduction">Introduction</h2>
The Spring Framework is a very robust framework, released in 2002. Its core features can be applied to plain Java applications or extended to complex, modern web applications.
As it's constantly being updated and is following new architectural and programming paradigms, it offers support for many other frameworks that work hand-in-hand with it.
With such a vast array of functionalities, it's only normal that it introduces us to some new annotations, which are a key part of developing Spring applications.
Spring's configuration is fully customizable, which was originally done through XML configuration files. However, this approach has become outdated, and most people nowadays resort to annotation configuration.
That being said, this series of articles aims to unravel the options you as a developer have to configure and use the Spring framework:
<ul>
<li><a target="_blank" href="/spring-annotations-requestmapping-and-its-variants/">Spring Annotations: @RequestMapping and its Variants</a></li>
<li><a target="_blank" href="/spring-annotations-core-framework-annotations/">Spring Annotations: Core Annotations</a></li>
<li>Spring Annotations: Spring Cloud</li>
<li><a target="_blank" href="/spring-annotations-testing">Spring Annotations: Testing Annotations</a></li>
</ul>
<h2 id="springcloudannotations">Spring Cloud Annotations</h2>
<a rel="nofollow" target="_blank" href="https://spring.io/projects/spring-cloud">Spring Cloud</a> is a great extension to the already robust Spring Framework. It allows developers to effortlessly and painlessly build common patterns when it comes to cloud-based architecture such as setting up circuit breakers, discovery clients, routing etc.
We've already published several articles covering some of these topics, so if you'd like to see these annotations on practical hands-on examples, these are a great start:
<ul>
<li><a target="_blank" href="/spring-cloud-service-discovery-with-eureka/">Spring Cloud: Service Discovery with Eureka</a></li>
<li><a target="_blank" href="/spring-cloud-routing-with-zuul-and-gateway/">Spring Cloud: Routing with Zuul and Gateway</a></li>
<li><a target="_blank" href="/spring-cloud-hystrix/">Spring Cloud: Hystrix</a></li>
<li><a target="_blank" href="/spring-cloud-turbine//">Spring Cloud: Turbine</a></li>
<li><a target="_blank" href="/spring-cloud-stream-with-rabbitmq-message-driven-microservices/">Spring Cloud Stream with RabbitMQ: Message-Driven Microservices</a></li>
</ul>
<h2 id="enableconfigserver">@EnableConfigServer</h2>
Spring Cloud introduces us to several useful tools, each needing some sort of configuration.
If we're using multiple tools, it would be logical to store all configuration details in a single place, similar to an <code>application.properties</code> file.
To do this, we annotate a class with the <code>@EnableConfigServer</code> annotation, applied on class-level:
<pre><code class="hljs">@SpringBootApplication
@EnableConfigServer
public class SomeApplication {
 public static void main(String[] args) {
 SpringApplication.run(SomeApplication.class, args);
 }
}
</code></pre>
This annotation tells Spring where to search for configurations and by creating a centralized server configuration like this, other applications can talk to it via it's port - which by default is <code>8080</code>.
<h2 id="enableeurekaserver">@EnableEurekaServer</h2>
When developing a project with a microservice architecture, especially when there's numerous services that should be working together, we're faced with a problem. The way these services talk to each other.
We could hardcode all the names and ports in a property file but this is bad practice and isn't scalable at all. Even if we did, what happens when there are multiple instances of a service? Which one responds to the request?
To solve these, we can rely on <a target="_blank" href="/spring-cloud-service-discovery-with-eureka/">Service Discovery</a> via Eureka.
Very similar to the <code>@EnableConfigServer</code> annotation, we'll make a Eureka server by annotating a class with <code>@EnableEurekaServer</code>, which can now be used to lookup other services registered to it and manage them:
<pre><code class="hljs">@SpringBootApplication
@EnableEurekaServer
public class SomeApplication {
 public static void main(String[] args) {
 SpringApplication.run(SomeApplication.class, args);
 }
}
</code></pre>
<h2 id="enableeurekaclient">@EnableEurekaClient</h2>
A Eureka Server is nothing without its services. Each service that we want to put on the radar for our server should be annotated with the <code>@EnableEurekaClient</code> annotation.
As an alternative, we could use the <code>@EnableDiscoveryClient</code> annotation, which comes from <code>spring-cloud-commons</code>. Though, if you know the specific implementation you'll be using, it's better to be specific. If you're using the more genetic <code>@EnableDiscoveryClient</code> annotation, Spring will choose the implementation based on the <code>.jar</code>s present in the classpath.
<pre><code class="hljs">@SpringBootApplication
@EnableEurekaClient
public class Application {
 public static void main(String[] args) {
 SpringApplication.run(Application.class, args);
 }
}
</code></pre>
<h2 id="enablediscoveryclient">@EnableDiscoveryClient</h2>
The default discovery client annotation which marks a class as a service that should be put on the radar for a server.
<h2 id="enablecircuitbreaker">@EnableCircuitBreaker</h2>
Again, when working with microservices, we're faced with a big problem. It's common for services to work with other services to complete certain requests.
Let's say Service A calls Service B, which relies on Service C to complete a request. Now let's say Service C completely fails due to a network error or an overload. What happens next is a cascading error in the flow of logic coming back up to Service A.
What we can do to rectify this is implement circuit breakers. Each service should have a circuit breaking point, and if something wrong occurs, they &quot;open their circuits&quot; so that the problem doesn't transpose onto other services. In this case, the circuit breaker of our choice isolates the failing service so that other services can't call it and fail as well.
The <code>@EnableCircuitBreaker</code> annotation is applied on class level, for each and every service in our microservice architecture:
<pre><code class="hljs">@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ServiceA {

 public static void main(String[] args) {
 SpringApplication.run(ServiceA.class, args);
 }
}

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ServiceB {

 public static void main(String[] args) {
 SpringApplication.run(ServiceB.class, args);
 }
}

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ServiceC {

 public static void main(String[] args) {
 SpringApplication.run(ServiceC.class, args);
 }
}
</code></pre>
The circuit breaker pattern in Spring is implemented through <a target="_blank" href="/spring-cloud-hystrix/">Spring Cloud: Hystrix</a>.
<h2 id="hystrixcommand">@HystrixCommand</h2>
For the circuit breaker pattern to work fully, we can't only annotate classes. Since in almost all situations we can &quot;expect&quot; that a method may be risky, in the sense that it might fail when called, we mark them with <code>@HystrixCommand</code>. Alongside the annotation, we can also add a flag that points to a different method to run if the original one fails:
<pre><code class="hljs">@GetMapping(value = &quot;/personalized/{id}&quot;)
@HystrixCommand(fallbackMethod = &quot;recommendationFallback&quot;)
public Product[] personalized(@PathVariable int id) {
 Product[] result = restTemplate.getForObject(&quot;http://recommendation-service/recommendations&quot;, Product[].class);
 return result;
}

public Product[] recommendationFallback(int id) {
 System.out.println(&quot;=======recommendationFallback=========&quot; + id);
 return new Product[0];
}
</code></pre>
<h2 id="ribbonclient">@RibbonClient</h2>
<a rel="nofollow" target="_blank" href="https://github.com/Netflix/ribbon">Ribbon</a> works as a load-balancer on the client side and gives you control over the HTTP and TCP clients.
In most cases, when using a discovery client such as Eureka, you don't need to use this annotation as it's applied by default. In the vast majority of cases the default options are good enough to take care of load balancing, but if you require to tweak them, you can do so:
<pre><code class="hljs">@Configuration
@RibbonClient(name = &quot;custom&quot;, configuration = CustomConfiguration.class)
public class SomeConfiguration {

}
</code></pre>
The <code>CustomConfiguration</code> class should also be a <code>@Configuration</code> annotated class with the custom Ribbon settings set-up as beans.
<h2 id="loadbalanced">@LoadBalanced</h2>
The <code>@LoadBalanced</code> annotation is used to mark <code>RestTemplate</code>s that should work with the <code>RibbonLoadBalancerClient</code> when interacting with your services:
<pre><code class="hljs">@RestController
@RibbonClient(name = &quot;custom&quot;, configuration = CustomConfiguration.class)
public class SomeApplication {

 @LoadBalanced
 @Bean
 RestTemplate restTemplate(){
 return new RestTemplate();
 }
 // ...
}
</code></pre>
This annotation basically allows the <code>RestTemplate</code> to leverage its built-in support for load balancing.
<h2 id="conclusion">Conclusion</h2>
The Spring framework is a powerful and robust framework which really changed the game when it comes to developing web-applications. Amongst it's myriad of projects, the Spring Cloud module is a great extension of the original framework.

Java Iterable Interface: Iterator, ListIterator, and Spliterator

Python for NLP: Movie Sentiment Analysis using Deep Learning in Keras

Serverless Python Application Development with AWS Chalice

Creating Python GUI Applications with wxPython

Spring Annotations: Spring Cloud

Introduction to Bash

Traveling Salesman Problem with Genetic Algorithms in Java

Python for NLP: Word Embeddings for Deep Learning in Keras

Introduction to Genetic Algorithms in Java