Forem: Pranith Hengavalli

Automate Anything Easily With Applescript

Pranith Hengavalli — Fri, 15 Mar 2019 22:12:51 +0000

If there's a series of actions you find yourself doing really often, it'll probably save a lot of time in the long term to write a script to do it. AppleScript lets you automate just about anything on your Mac, from file I/O to interactive prompts and filling in web browsers. It can even automatically reply to your messages for you!

Unlike regular programming languages, its deep integration with OSX lets you create rich GUIs and complex actions that would require a lot more effort to do a more universal language like Python.

Recently I wrote a script that takes the name of my git branch and automatically builds iOS and Android variants, and sends me a notification on Slack when it's all done. This would otherwise involve a lot of manual effort since the builds are started on two separate Jenkins web dashboards. This is something I usually do a few times a day, and I probably save a few minutes cumulatively thanks to the script. 😄

To start writing a script, open Script Editor on your Mac.

In many cases, you can generate an AppleScript by just pressing the record button and doing the sequence of actions once. The script editor generates code for each action as you perform it.

One of the cases where AppleScript doesn't work as well is when interacting with the content on web pages. For this I like to execute Javascript directly on the page, which I think is a more powerful approach than detecting elements in the GUI.

The following snippet defines a function called clickClassName that clicks on the selected element on the page, in this case the 3rd button.

to clickClassName(theClassName, elementnum)
  tell application "Safari"
    do JavaScript "document.getElementsByClassName('" & theClassName & "')[" & elementnum & "].click();" in document 1
  end tell
end clickClassName

clickClassName("button", 3)

User input

You can accept user input in your scripts, and you get these pretty dialog boxes that come with various input type options. This is useful to pick options at the time of running the script.

display dialog 
    "What website do you want to see?" buttons {"Dev.to", "StackOverflow", "Hacker News"}
set theSite to button returned of result
display dialog theSite

Persistent Data

Properties are saved between launches, and can be used to remember your last input.

property variable : 0
display dialog variable
set variable to 100

Will show 0 on the first run and 100 on the second run.

A surprising number of applications support automation. Go to File > Open Dictionary to see a list of installed applications that support AppleScript control, as well as documentation about supported commands.

Finally, you'll need to save it as an application so it won't open the script editor each time you try to run it. Go to File > Export > Set the file format to 'Application' > Save.

The best scripts are the ones you write for yourself, but here are some useful scripts to get you started:
https://www.computerworld.com/article/2524645/10-applescripts-to-make-you-love-your-mac--even-more-.html
https://www.smashingmagazine.com/2009/05/mac-hacks-17-applescripts-to-make-your-life-easier/
https://drago86.wixsite.com/scripting/scripts

Best way to partition repetitive static html?

Pranith Hengavalli — Mon, 03 Dec 2018 15:25:17 +0000

I want to make multiple pages for a site, and they all have common header and footer segments. What is the best way to write this code so I won't have to make the same change across multiple html files?

I guess the modern approach is to go with React-router, declaring the repeated header and footer as components and then using something like Gatsby to render it server side.

I also came across handlebars.js which appears to be what I'm looking for, but I want to choose a method with the most minimal initial setup, or at least an environment that is easy to reproduce.

Deploy Static Websites Instantly on dragdrop.site

Pranith Hengavalli — Wed, 21 Nov 2018 10:28:37 +0000

I'm a huge fan of Glitch. I've used it at countless hackathons to quickly host Node.js projects without having to worry about deploying a server, and the online editor with autosave has been an amazing way to work with teams when quickly building a prototype app.

However, I took a web design class recently where were asked to host our project sites on the internet, but many of my peers had no experience with things like XAMPP and would constantly ask me for help.

This lead me to create dragdrop.site.
It's a simple service that lets you create a static website by dragging html, css and js files from your computer into the browser window. It instantly returns a new subdomain that looks like 'xyzab.dragdrop.site', which you can use to share your project with your friends.

I guess a key benefit of doing it this way is that you can develop it locally on your favourite tools, and deploy it in a very visually distinct way. It worked great for my classmates.

I encourage them to try services like Firebase to set up backend functions for forms ands stuff.

I'm looking for some feedback and ideas to make the service more useful. I hope to add support for HTTPS using LetsEncrypt soon, as well as allowing users to pick their own subdomain names. Also eventually user accounts so you can switch between computers. Also eventually middleware if people want it.

ELI5: a quantum web app (in Javascript)

Pranith Hengavalli — Fri, 16 Nov 2018 15:35:12 +0000

I was having a conversation with a friend who is studying Quantum Programming as a part of his Masters degree. As he described the concept of state entanglement to me, I started to feel like the concept is very close to Redux and state management on the web. So, I wrote this post to elaborate some of my thoughts.

What is a quantum programming language?

A quantum programming language is really a specific type of machine code targeting a quantum computer, which is based on quantum mechanics compared to classical mechanics.

A classical computer has a memory made up of bits, where each bit is represented by either a 0 or a 1.

A quantum computer, on the other hand, maintains a sequence of qubits, which can represent a 0, a 1, or any quantum superposition of those two qubit states.

Quantum computers may be able to efficiently solve problems which are not practically feasible on classical computers, and thanks to the Church–Turing thesis, we know that a classical computer can technically simulate a quantum algorithm.

Why Quantum Programming?

IBM has unveiled it's cloud quantum computer for public use, Microsoft has revealed the Q# quantum programming language, and D-Wave Systems partnered with NASA to release the D-Wave-2. It looks like Quantum Computing is becoming a reality!

Since quantum programming is based on quantum mechanics, it benefits from some of the cool phenomena associated with it.

Quantum entanglement is a physical phenomenon which occurs when a group of particles interacts in ways such that the quantum state of each particle cannot be described independently of the state of the others, even when the particles are separated by a large distance.

Let’s say we have two particles A and B. Both particles are in superposition of possible states — in this case they both turn red and blue at the same time. If we measure the colour of A, and it picks red, and someone else an instant later measures B — B will always be blue.

Entanglement means that somehow B knew, instantaneously, what A picked, regardless of the distance between A and B.

States in Web Applications

In web applications today, we face a similar challenge in maintaining the same state on the front end and the back end. With growing use of various modern hacks such as Redux/Flux, it is clear that we need a more elegant solution to state management across physical distance.

Quantum State Entanglement

How is the actual data represented? This is done based on a process called superdense coding. Superdense coding is a method of sending two traditional bits of information (00, 01, 10, or 11) using a single qubit.

Lets assume the state of our web app is encoded into an array of such qubits. Our goal would be to entangle the state from the server side with the state on the client side.

We add the Hadamard gate (H) with 1 qubit for adding superposition property.
We add Controlled-NOT gate (CX) , a two-qubit gate that flips the target qubit if the control is in state 1. This gate generates entanglement.

The combination of these two quantum logic operations brings our pair of qubits to a Bell state.

Bell State

The Bell states are specific quantum states of two qubits that represent the simplest examples of quantum entanglement.

Code

The following code can really only run on a quantum computer :P

# Assuming we have two qubits, qr[0] and qr[1]
# Add the H gate in the Qubit 1, putting this qubit in superposition.
qc.h(qr[1])

# Add the CX gate on control qubit 1 and target qubit 0, putting the qubits in a Bell state i.e entanglement
qc.cx(qr[1], qr[0])

# Add a Measure gate to see the state.
qc.measure(qr[0],cr[0])
qc.measure(qr[1],cr[1])

# Compile and execute the Quantum Program, since it needs to be simulated
results = qp.execute(['HelloWorldCircuit'], backend,timeout=2400)

Quantum programming is still a highly theoretical field, and we won't really see the performance improvements from it until we build a much more practical quantum processor. However, I hope that being more aware of the paradigms makes you have more to worry about in your future work and projects. :D

Designing A Voting System For 1 Billion on the Blockchain (Part 2) - How To Keep A Secret

Pranith Hengavalli — Fri, 19 Oct 2018 12:32:56 +0000

This post is part two of a series about large scale voting on the Blockchain. In my previous post, we discussed what a large network would look like, and how consensus could be achieved with so many votes placed at the same time. This post focuses on how it works from the perspective of a single voter.

One of the key features of Blockchain as we know it is the 'decentralised ledger', a public store of every single block that is synchronised across all participants. This system was traditionally designed to allow for data to be open and publicly verifiable, but this could have negative impacts on elections. For instance, being able to tally the votes privately before the election is finished could lead to confirmation bias in minds of the voters.

Some of the key considerations from the voters' perspective are:

Choice of candidate must remain secret
Vote counting should be public and accountable
Tamper proof by a third party

The ancient system of dropping papers in a ballot box is really great at this. All the votes are mixed up in the box, no secret votes were present before they started, and at the end, all they have to do is count all the papers in public. One could add that thanks to VVPAT (Indian voting machines print each vote on a slip and drop them into a sealed box), one simply has to follow their vote until the counting rooms to be sure that their vote was indeed placed. Too bad they don't actually count the printed papers, and the error begins with the manual uploading of votes from each voting machine, 3840 votes at a time. Entire batches could be misrepresented or misplaced.

A VVPAT machine printing out a ballot

The blockchain-based voting procedure could look a little like this:

A. EVM Initialisation

In India, voters are each registered to areas known as constituencies, where they are allowed to cast a vote. This makes it much easier to verify that an individual exists on paper, something that becomes increasingly difficult in remote areas without active network connectivity.

In the case of a Blockchain EVM, it would be initialised before the starting of each election. It receives a list of eligible voters for that region, as well as a unique key that is used to sign votes while casting them. This can be done at the last possible minute before elections begin, while network is still available.

B. Voter Authentication

When a voter identifies themselves with a voter ID, it is verified against the local voter list. If the ID is present, a key-pair is generated for the voter, with the 'opening' private key stored against their name and the public key used to encrypt or 'seal' their vote choice. This sealed choice is then stored on the local ledger, ready to be sent to the central voting nodes.

C. Vote Accumulation

One of the biggest problems faced in India is the communication barrier experienced by people living in remote regions. Though network coverage has greatly improved, it still isn't reliable enough in remote areas to handle too much traffic. This is why the current EVMs still need to be physically shifted to the Election Commission for counting.

With better connectivity, I suggest a more hybrid approach to this, where votes are stored in chunks locally until a stable connection is established. Chunking votes also makes it harder to place individual fraudulent votes from a rogue machine.

D. Vote Casting

When enough votes accumulate and a stable internet connection is established, a chunk of votes is pushed to the delegated voting servers. These chunks are signed by the EVM with the key that was created during initialisation. The chunks can be sent to any of the available delegates, which can then add them to the longest available vote chain.

E. Vote Counting

When the voting period is declared closed, a signal is sent from the voting servers to EVMs, requesting the 'opening' private keys for all the 'sealed' votes. Since votes from each constituency are grouped in chunks, it is easier to find chunks from a particular EVM and unseal all corresponding votes with the matching private keys. Any votes that were placed by unauthorised EVMs would remain unopened as they would be unable to send opening values to the voting servers.

One of the primary advantages of this method is that there is much more accountability for each vote, as the vote cannot be counted until the second round of confirmation when the votes are unsealed. Since the Voter ID is not sent back from the EVMs, it becomes impossible to associate the choice made and the voter ID from the perspective of the counting servers.

Finally, the unsealed votes are counted and we can conclude how many votes were placed for each candidate.

Of course, practical implementation of such a system could take a long time. We would need to design robust hardware, conduct practical tests, and address the fact that the new system would create a whole new set of vulnerabilities. The cost of manufacturing alone would encourage policy makers to prefer a solution which can be built on top of the existing voting infrastructure. However, I hope we can spark a conversation about how blockchain design concepts present us with a brand new way of building systems that are performant and secure at massive scale.

Designing A Voting System For 1 Billion on the Blockchain (Part 1)

Pranith Hengavalli — Wed, 10 Oct 2018 15:35:06 +0000

The system of voting to (s)elect the the governing body of a nation is the core concept of Democracy. In the earliest of its forms, the Spartans would democratically elect their leaders by casting stones into marked bowls. Today, we use "cutting-edge" technology to conduct these vital election procedures, but since the prize at stake is control of the population, elections continue to be an easy target for a malicious candidate who is intent on seizing power. With the recent revival of Blockchain and increased interest in decentralisation, consensus and Merkle trees, perhaps we are now better equipped with techniques to solve large scale voting.

Voting in the Past

In India, nation-scale elections are conducted using an Electronic Voting Machine (EVM) that is distributed to various voting regions(we call them constituencies), spanning from large metropolitan cities to remote villages with no connectivity. Each machine can hold 3840 votes, and the voting machines are manually transported to the central voting commission for counting. This process is difficult and time consuming, and there have also been reports that the procedure is prone to manual error or intentional miscounting1.

More recently the Election Commission of India has devised a system called the 'Voter Verifiable Paper Audit Trail' (VVPAT), which involves the voter's choice being printed on a physical receipt which is displayed briefly before being dropped into a sealed box. This allows the voter to know that the vote was placed correctly and addressed previous concerns that votes were being cast to a default candidate on a potentially rigged machine. Further, the paper trail would add more accountability in the counting process, unless, somehow, a huge number of them were to go missing :^).

The key benefits of this system are:
a. The hardware is designed to be extremely robust, and can be run off a 6 volt alkaline battery even in remote regions without power.
b. The polling is offline, and all machines are returned to the election commission who is responsible for preventing voter fraud.
c. Indians have more faith in a paper verifiable system, as they feel purely software based solutions would be more vulnerable to manipulation.

It doesn't stop there. Nepal, Bhutan, Namibia and Kenya have purchased India-manufactured EVMs with the intent of employing them in national elections. I begin to worry that being more reliant on labour-intensive manual counting processes might not be the best way forward.

Further, the manual authentication method of physically identifying yourself in your registered voting constituency is also something that we should avoid, potentially allowing people to place votes for a candidate in their home state even if they are travelling, which can drastically increase voter turnout.

Software Based Voting

In traditional voting systems, votes are cast on a client (either dedicated or through a website), and the choice is then submitted to a server where a central database keeps track of all the cast votes. Each individual vote is stored in the database, so it is possible to re-count all the votes, instead of merely tracking the votes with a counter for each candidate. This makes it easier to verify that no voter fraud has occurred, such that there were no duplicate votes or if a vote failed to be cast. Since votes are not placed until they are sent to the server, we can ensure that the server validates the voter's identity and choice to prevent fraud.

While any of the more obvious security concerns of a software application could apply, some of the more domain-specific ones are:

A single voting server would not be able to handle the load from many votes being placed at once. We would need to use sharding or allow voters to place votes to one of many servers.
As the number of voting servers increase, it becomes more difficult to ensure that no duplicate votes are placed across servers.
An attacker could spoof a voting machine's signature over the network and place unauthorised votes.

Why use the blockchain?

Blockchain architecture provides great solutions to many of our key problems:

High volume: Since voting is decentralised, votes can be placed across nodes on the network, without requiring a single central server taking all the load.
Merkle trees: Can ensure that only the longest chain of verified votes is accepted, making it difficult to place unauthorised votes or to modify a vote that has already been placed.
Redundancy: There are multiple exact replicas of the voting results, created at the time of voting. It would be necessary to fake a vote on all of the redundant servers.

The original implementation of the Blockchain in Satoshi Nakamoto's Bitcoin used a technique called Proof of Work to add new blocks to the chain. This method requires all miners on the network to solve a difficult mathematical problem for a reward, while also adding all previous transactions to the chain. This can be very intensive, and one of my professors smugly told me that it would cost Rs. 250 to propagate a vote in a PoW blockchain across the nation.

Consensus is the process of making sure that every node can agree on all the votes that have been placed, and that their ledgers are exactly the same and updated. Achieving faster consensus at scale is one of the problems in the spotlight of various ICOs and Cryptocurrency focused startups. This would lead to faster confirmation of transactions which could probably bring us one step closer to the perfect solution. Right now, it takes 15-30 minutes to confirm a Bitcoin transaction, which is a whole half hour of wondering if you sent it to the wrong address, or at least that much time in which the receiving party will have to wait before they can access it. Visa, in comparison, can handle an estimated 24,000 transactions per second. That's more like it.

Delegated Proof of Stake

Delegated Proof of Stake (DPoS) is one of the faster consensus algorithms, as used by the EOS token. They claim to confirm 3,000 transactions a second across 21 'delegated' servers. The catch with Proof of Stake is that EOS doesn't aim to achieve consensus on all available nodes. In each confirmation round (known as an epoch), a random server is chosen to be the 'block producer', the node responsible for creating the new block and sending it to all the other delegates. The block producer then tallies all votes that were placed on it and sends it to every other delegate to confirm it. If any unauthorised node tries to propose a block out of turn, the block is rejected by it's peers since only the chosen delegate for each epoch is allowed to propose a block.

A similar architecture can be proposed for voting, with the voting machines acting as regular nodes and a set of dedicated servers acting as delegates for vote confirmation.

When the network adds a block of votes to the chain, one of the ‘delegates’ is randomly chosen to confirm the validity of the votes that make up the current block. This block is then propagated to all the other delegates to achieve consensus on the votes that have been placed. A malicious actor would have to bypass the voter authentication method and successfully place the invalid vote on the randomly chosen delegate server.

By distributing the vote confirmation effort across multiple delegates, we can evenly spread the load faced during balloting. Through deterministic selection of the block producer in each epoch, we can ensure that the system maintains redundancy in the case of certain delegates experiencing excess load or unexpected failure. In this manner we will design a fault tolerant system that will significantly streamline the balloting process.

I've never really written a piece like this before, and I'm not too sure how to write a conclusion so I'm looking for suggestions and feedback :)

In part 2, we discuss the voting process, including voter authentication, biometric hashing, offline voting.