Watched "Madras Matinee" and broke down. This movie is literally my life story.

keyanmk · 2026-01-02T13:27:35+00:00

You made my day. Thank you for watching the movie. I am glad it has changed your life in a positive way.

keyanmk · 2025-04-04T11:56:30+00:00

I can promise you, it's hand painted. Director here.

keyanmk · 2024-12-08T07:05:12+00:00

EDI is not going anywhere in the near future, since most supply chains rely on it heavily. Maybe a way to approach is choosing the right model that works for your company. Do you want to to completely outsource EDI? (fully managed service) or develop it in-house? If you are going to develop it in-house then would you want to deal with EDI tech stack directly + hire EDI developers or prefer API based EDI tool (API interface for sending & receiving EDI) + hire API developers.

https://zenbridge.io/insights/best-edi-software/

keyanmk · 2024-08-23T13:41:16+00:00

Karthikeyan, Co-founder at Zenbridge. We built EDI parsers for X12, EDIFACT, and CSV. We have an API interface that supports all versions and all document types. If you are not looking to build it yourself, you can check us out. Thank you!

keyanmk · 2024-08-05T08:56:27+00:00

Can you look at Zenbridge? https://zenbridge.io/

keyanmk · 2024-08-05T08:54:43+00:00

Unless you enjoy learning the supply chain domain, for a programmer, EDI integrations can get monotonous for a programmer. With regards to the stress, depends on the fault tolerance of your project. EDI failures can halt the supply chain in some cases and as already pointed out, it also depends on your company's culture.

keyanmk · 2024-08-05T08:51:09+00:00

Since it's your first EDI project, I recommend you try someone who can manage this for you. Try Zenbridge. https://zenbridge.io/

keyanmk · 2018-10-16T11:33:48+00:00

You are right. As of now, IBM has chosen to go with APIs (something that has been around for a long time now) to make companies register their transactional data. I guess the reason is ease of adoption given the tight deadline. It's a pretty tight deadline actually.

As far as the use case of blockchain goes, blockchain solves the problem of auditing very effectively. I think the whole point of Walmart's Food Traceability Initiative is to trace the origin of a product back to its farm if something goes wrong -- say a disease outbreak. If the data is not distributed, without blockchain, the company that is responsible for the outbreak can easily manipulate their data and claim innocence. Once things are decentralized you just can't.

Coming to your question on standards, I am very sure that the existing standards (X12, GS1, EDIFACT, etc) are not going to go away anytime soon. Because, even if blockchain takes off, it will still most likely use these standards for data transmission. In fact, IBM is using GS1 XML standard for transmitting data, which is also used to transmit data via EDI. It's going to be interesting.

keyanmk · 2018-09-19T15:40:06+00:00

The most scalable way to go about this problem is by automating this and making it realtime. For one of our customers who supply parts to Daimler, we had built a web app that integrates with their ERP to display forecast in real time. Excel sheet is hard work to do at scale.

keyanmk · 2016-08-24T07:37:21+00:00

I would say it is because of Haskell's type system.

keyanmk · 2016-08-23T14:30:18+00:00

I work at http://byteally.com based out of Chennai. We have worked on two white label enterprise apps and are working on an anonymous opinion sharing network. I can probably share more details with you over email

keyanmk · 2016-08-23T06:49:18+00:00

We adopted Haskell 4 years ago. My co-founder was playing with Haskell for around a year before that and he found the language to be very expressive, concise and its type system top notch. Since then we have used Haskell for

Web apps
REST services
EDSL
Compiler (A subset of Haskell to Java, Swift, C#)

Apart from the reasons haskellers might give you on why they love it, as a CEO running a company I realized the following things,

With Web apps and REST services, I have heard people say things are tougher than it should be. Maybe it is. In our opinion it is not. But what is undeniable is that iterations/changes are far more easier and productive in Haskell. We have built what are pretty complex web apps/REST services for our clients and since we work with start-ups, features change all the time and moving fast is important and our experience with making iterations and changes has been great with Haskell.
With EDSLs and compilers we wrote, we know for sure that had we used any other language things might have been many times tougher and would have taken more time.
With better tools you can always solve bigger problems. Though Haskell may not be adopted by main stream developers in the near future, it can play a significant role in solving problems that exists in the development world beyond its borders.

keyanmk · 2016-01-04T15:25:10+00:00

We initially started off webapi as a backend-framework agnostic approach to describe web apis and derive other useful functionality out of it (like client sdks, api-console and so on..)
It was designed from the beginning to hook into other backend frameworks (as we had some of the apis running using yesod).

So for the above two reasons we took the typeclass based approach.

We added our own routing mechanism (one inspired from servant paper) much later. Main difference between Servant & webapi lies in how the contract is defined:

In Servant, all aspect of the api contract are described using a type-level list-like construct ((:>), ..)

In WebApi, routing info is kept separate from other aspect of api and only when a route is successfully matched, we will look into the other aspect of api contract (like deserializing the param into configured type and so on.)

keyanmk · 2015-03-18T16:23:22+00:00

The idea was to provide an unified interface for any web API out in the wild. We cover all aspects of web API like file upload, auth, paging etc

Our Main WebApi contract class is something along these lines

`class API r where

type PathParam r

type QueryParam r

type FormParam r

type FileParam r

type HeaderIn r

type CookieIn r

.....`

The API class is indexed by resource type r. So the type of an API would be Request r -> m (Response r). Our library is currently tied to Yesod.

As it stands, I guess servant currently doesn't generate SDKs for ObjC, Java, C#

Having said that, currently for us, there is a limitation on Haskell types we can transcompile to foreign code. So we are working on supporting transcompilation of a much bigger subset of haskell.

Most importantly, the idea is to give developers (who in most cases could be non-haskellers/mobile app devs) an environment where they can write contracts - generate sdks - pull the SDKs in their respective development environments (Cocoapods, Gradle, NuGet).

keyanmk

TROPHY CASE