DEV Community: ちぇん

I made a battle game for Wordle

ちぇん — Thu, 03 Mar 2022 12:52:36 +0000

here

How do you think of it?

Full Stack Engineer Career Path

ちぇん — Mon, 04 Oct 2021 00:18:57 +0000

Tell me your career path

Don’t develop API by yourself. Leave it to Hasura completely.

ちぇん — Sat, 11 Sep 2021 01:30:52 +0000

What I want to tell you about

the effectiveness of Hasura
- Effect of reducing development man-hours
- High flexibility
- Secure

Challenge of "reduction of development man-hours"

Due to the recent shortage of engineers and rising unit prices, there is a problem that sufficient development man-hours cannot be secured. I think every company is taking various measures to reduce the development man-hours.

Utilization of new technology
Use of familiar technology
Process review
Thorough automation
Review of scope
Stop excessive quality

etc. This time, I propose that there is a possibility that the development man-hours can be reduced by "utilizing new technology" at the top.

Suppose you decide to make an app like this

Let's say you decide to make an app like this.
A simple online whiteboard tool that needs to have the following features:

You can write on sticky notes
You can move sticky notes
Sticky note color will be user-specific
You can erase sticky notes (only sticky notes you made)
You can share the position and contents of sticky notes in real time.
You can switch boards
You can log in with Cognito

The development required for the backend is as follows

In order to develop the above functions, the back end needs to be developed as follows.

DB

Table design (Board, Note 2 tables)

API

Get a list of sticky notes linked to the board (deliver the latest value with websocket)
Add sticky note (Create by linking with Cognito user ID)
Update sticky note text and position
Delete sticky notes (so that an error occurs except for the ones you created)

infrastructure

Deploy to Fargate / ECS
Cognito cooperation

How much man-hours do you estimate?

If you simply implement it and make something that works, saying "backend only + no testing required", how long would you estimate?

① 1 hour
② 1 day
③ 1 week
④ 1 month

Hasura can do it in an hour

In fact, when I developed the backend for the above app, it took only 1 hour to complete.
The reason whyI was able to reduce such dramatic man-hours is because I used Hasura.
Introducing four functions.

① API automatic generation

Hasura automatically generates GraphQL API from table definition.
Query methods that allow flexible search, Create, Update, Delete, etc. are also automatically generated, and simple but sufficient CRUD can be done.

② Cognito cooperation

Hasura provides a webhook and JWT authentication method.
Easily implement JWT authentication with AWS Cognito. Of course, it can also be linked with Auth0 and firebase authentication.

③ Access control

You can control the methods that can be executed for each Role of the API executor.
Access control can be described by referring to the user ID and group ID in JWT, and restrictions such as "Delete is possible only when CreatedBy matches the user ID" can be applied.

④ Subscription

Subscription is a Websocket-based real-time query that automatically delivers the latest values when the monitored resource is updated.
The interface is the same as Query, so it's very easy to use.

These functions greatly reduce development man-hours

This is the only work actually done in this development

DB creation
Cognito cooperation
Access control settings
Deploy to ECS using Copilot

If you get used to these, you can complete them in about an hour. Therefore, if it is a simple CRUD API, a significant reduction in development man-hours can be expected.

Concerns about Hasura

After reading the above, some people may have the following concerns.

① Where do you write the business logic?
② I don't want to use GraphQL on the front end. REST is good.
③ What will happen to the development environment such as version control?

Correspondence will be described for each.

① Where to write business logic

Hasura offers two options: Actions and Remote Schema.

As shown in the image above, Actions uses Websocket to pass through the process to another HTTP endpoint. You can write custom logic by preparing a web server or Lambda that processes custom logic.

Remote Schema creates a completely different GraphQL server by yourself and combines Hasura with the schema. You can build a GraphQL server that processes business logic with Apollo etc. and combine it with Hasura without any unnaturalness.

② I don't want to use GraphQL at the frontend

Hasura has a function to register a query and make it a REST API
Backend can be developed with GraphQL, front with REST

③ What will happen to the development environment?

Since all Hasura metadata (access control, etc.) is stored in the DB, developers should look at the DB in the same development environment.
Hasura will be placed in ECS and will have ELB IP restrictions so that only developers can access the console.
Since the metadata can be exported, it can be managed on Github / can be applied to the production environment.

Conclusion: Hasura is worth considering for practical use

Hasura is, in a nutshell, a "SQL client that can be called from the front"
In fact, Hasura uses an internal implementation to model the GraphQL tree structure and convert it to SQL.
In short, this is equivalent to skipping the old backend.
If you leave simple CRUD to Hasura, it will be possible to significantly reduce development man-hours.

I’ve created an OSS library that makes it easy to create real-time web apps

ちぇん — Wed, 08 Sep 2021 13:22:14 +0000

I have developed an OSS

I have developed a OSS library called Realtimely that makes it easy to introduce fun real-time elements into React apps.
Realtimely uses GraphQL and communicate with AWS Cloud by websocket. Programmers who use this library can implement a websocket-based real-time experience by simply using the hooks function provided by Realtimely without being aware of complicated technology.
For example, you can implement a feature of sharing the position of the mouse cursor like the gif below with about 10 lines of code.

import {useRealtimeCursor} from 'realtimely';

export default () => {
    const {onMouseMove, renderCursors} = useRealtimeCursor()
    return (
        <div onMouseMove = {onMouseMove}>
                {renderCursors()}
        </div>
    )
}

I made a demo page, so please feel free to try it.

From launch to release

Now, from here, I would like to write in chronological order how we actually planned and released it.

Number of developers : 1 person
Production days : 18 days
Costs : AWS Free Tier
Time spent in a day : 1 hour on weekdays 3 hours on holidays

8/19 (0th day from the start) Plan

The decisions made on the first day are as follows.

Use Case
- → Image of when to use this library
Product image
- → Image of how programmers use this library
Architecture
- → What will be used to achieve this?
- This time, I wanted to make it as low-code and scalable as possible (to make things easier).
Identify and schedule necessary tasks
- List what I have to do
- Estimate how long it will take

This time, I considered the use case with a fairly product-out idea, but I think that it is ideal to actually do it by the following procedure.
① Think about issues that are in trouble in actual development
② Find out if someone has already realized it
③ If it has been realized, consider whether it is really convenient or if there is another product image that is easier to use.

Anyone can publish OSS, but even if you create and publish something that has already been realized or is not based on troublesome, there is a risk that you will end up with a product that interferes with everyone's search.

8/20 (1st day from the start) Investigation

I searched for a library that could do what I wanted to do, read the documentation, and tried it out.
The library was a REST-based library for creating "high-performance real-time apps."
Since the purpose was high performance, it turned out that state management using cache etc is included in the function and it is too much, and that developers must develop the back-end from full scratch and it is not easy to use.
So I corrected the product direction, such as sharpening my product image so that Realtimely could be used easily.

Also, although the direction is different, there are many things that can be referred to because the realization is similar. I also looked at the HTTP response and used it as a reference for what kind of data structure looks good for my product.

8/21 - 8/26 (6th day from the start) First iteration

We implemented the sprint goal of "sharing cursor movement in real time" in the first 7 days.

Touch AWS AppSync

AppSync is a managed service for GraphQL servers. There is a function to automatically generate GraphQL schema and resolver by connecting with DynamoDB table.
This time, I'd like to enjoy low code, so I decided to use AppSync.

There are no-code and low-code systems, but they have their limit or service characteristic. AppSync is no exception to this example, and there was a need to design while taking care of the features of AppSync.

Design

I wrote down the API required to implement "move the cursor in real time", and examined whether it could be realized. This area was a form of thinking about "what you want to achieve" and "what you can do with AppSync".

DB Design

DynamoDB is a scalable NoSQL database with a key-value store. DynamoDB has HashKey and SortKey keys, and we design the DB so that these combinations are unique. RealtimeCursor has the following schema.

HashKey	SortKey
URL#{URL}	UserId#{UserId}

The {URL} and {UserId} will contain the actual values. The mouse cursor position (X,Y) and user information will be stored as Attributes for these keys.

Fast Implementation

The first and foremost thing I do in implementation is to focus on speed.
I don't care how dirty it is, as long as it does what I want it to do.
The reason for this is that I believe that the most efficient way to create a clean design is to write everything and then scrap and build.
I don't know what can be made common from the start.

Refactoring

When I was able to achieve what I wanted with roughly dirty code, I refactored it.
If it's a web service, you may decide to release something that works without refactoring first.
In this case, we had to redesign it with careful consideration of the responsibilities and interface, because it had to be easy to use as an OSS library.

8/27-8/30 (Day 11 from start) Second iteration

This is the second iteration of the sprint goal: "Implement visualization of user actions" (e.g., when a user presses a button, other people can see it, or when a user enters text, it can be seen on other people's screens).

The development went smoothly because the code base was refactored and I knew roughly what I could do with AppSync.

8/31 (12th day after the start) Create a demo page

I deployed the Next.js project that I used for development by using Serverless Framework. I could deploy it to AWS in 5 minutes.
Demo page

9/1-9/4 (Day 16 of development) Creating documentation

I used a documents framework called docusaurus to create the documentation. docusaurus is maintained by facebook and is very well done product.

First, I listed what I was going to write in a big list, and then I started to write.

Think about what I'm going to write.

[x] Introduction
[x] Getting Started
- [x] Installation
- [x] Demo
- [x] Realtime Cursor
- [x] Realtime User Presence
- [x] Realtime User Action
[x] API Guides
- [x] useXXX
[x] How it works
- [x] Architecture
- [x] Self hosted Backend
[x] RoadMap

Write documents

This is the hardest part. This was the hardest part.

Making it in English

Since docusaurus has the i18n feature, I made the document in English(Original is Japanese).
Basically, I just let google translate translate it and reviewed it briefly.

Deploy to Github Pages

This was also a feature in docusaurus, so it was easy to do.

Other tasks

Create a logo.

I used a logo generator.

Create a donation window.

I also created a donation window using ko-fi.
It connects to Stripe and allows you to donate by credit card.

9/5-6 (18 days after development) npm public

It's time to publish. For details on how to publish to npm, please refer to another article. This time, I'll write roughly.

Create an npm account

Create an account at https://www.npmjs.com/.

Compile TypeScript into a .js file.

Write tsconfig.json and then

tsc -d

yarn publish

You will be asked to login to npm, just enter your email and password.

publish

I could publish really easily.
After publishing

I've used the npm library for so long that I felt guilty about stepping into the ring with my dirty feet.

Debugging

I installed realtimely in a different repository and tried to use it, but it gave me an error and wouldn't work...
I used a day for debugging.

Library dependencies
Error in loading CSS
Dependent library error

The future

Since I prioritized the speed of release, the library is not production-ready at this point. I hope that you will use it only at the PoC level to see what it is like to add real-time elements to your application.

From now on, I'll be working on solving issues to make it production-ready and developing more user-friendly features. Please watch over us with warm eyes.

Document
Demo

A collection of patterns when developing APIs with AWS Lambda

ちぇん — Sun, 29 Nov 2020 12:47:47 +0000

Conclusion

When developing API with AWS Lambda, the following 4 patterns can be considered. Each has its advantages and disadvantages, so I think you will choose based on your requirements and member skill sets.

① Functions (separate source) pattern

② Functions (same source) pattern

③ Web Framework pattern

④ GraphQL pattern

Background

API development with AWS Lambda

It is possible to develop serverless API by combining AWS Lambda and API Gateway. By building without a server, you can obtain scalability and cost optimization without any hassle, and you can significantly reduce the operation cost because you do not need to monitor life and death.

Development patterns are not organized

Although serverless API development has many advantages, there are various development patterns and there is no consistent method. For example, Lambda can be deployed by manually uploading a zip, using a deployment support tool such as SAM / Serverlesss Framework, or using the online editor Cloud9. In some cases, the directories are separated for each function, and in other cases, the source code is shared and only the entry point is switched. Furthermore, it can be created not only with REST but also with GraphQL. I couldn't find a document that organized these patterns properly, so I decided to summarize them this time.

Lambda API development pattern

① Functions (separate source) pattern

Characteristic

No resources or source files are shared between Lambda
Lambda function resources are created as many as the number of API paths
If there is common logic, put it in Layer
This pattern will be used when developing with Cloud9

merit

Very loosely coupled because there are no dependencies between Lambda. Therefore, you can easily add or modify APIs.
Since resources are separated, Cloudwatch logs are output for each function, making error logs very easy to follow.
Since resources are separated for each function, it is possible to create a secure configuration because detailed policies can be set.

Demerit

Even if you put the common logic in the layer, you still have trouble with layer version control. Even if you update the layer, the already deployed Lambda functions refer to the old layer, so you have to redeploy all the Lambda functions once.
The logic placed in the layer does not complement the editor, which reduces development efficiency.
When using a deployment support tool such as SAM / Serverless Framework, the configuration file (template.yaml / serverless.yaml) tends to be complicated. If you need to pass environment variables to all resources, that alone will increase the number of lines in the config file.
While fine-grained policy settings for each function are beneficial, they are difficult to manage.

② Functions (same source) pattern

Characteristic

The same source file is used, but resources are separated because the Lambda function is created by switching the entry point (file name / function name) of each Lambda.
Lambda function resources are created as many as the number of API paths

merit

Common logic can be reused without using Layer
Since resources are separated, Cloudwatch logs are output for each function, making error logs very easy to follow.
Since resources are separated for each function, you can fine-tune the policy and create a secure configuration.

Demerit

Since the source file is shared by each Lambda, it is necessary to consider the range of influence when adding or modifying the API.
When using a deployment support tool such as SAM / Serverless Framework, the configuration file (template.yaml / serverless.yaml) tends to be complicated. If you need to pass environment variables to all resources, that alone will increase the number of lines in the config file.
While fine-grained policy settings for each function are beneficial, they are difficult to manage.

③ Web Framework pattern

Characteristic

API Gateway passes the received request to Lambda as it is, and the web framework on Lambda performs routing etc.
API Gateway is an integration with proxy resources. (The path variable will look like / {proxy +})
You need to use a library that connects the interface between Lambda and Web Framework (eg aws-serverless-express, challice, Serverless Framework Plugin, etc.)

merit

If you have knowledge of Web Framework, you can develop without knowledge of Lambda.
It's just wrapping the web framework in a library, which makes it very easy when you need to move from serverless to EC2 or on-premises.

Demerit

Can only be used with web frameworks that support libraries
It will be a structure that tends to be a monolith
The size of the deployment package will increase. However, this can be solved by putting the dependent packages on the layer.

④ GraphQL pattern

Characteristic

Use Apollo Server on Lambda to put the GraphQL server on Lambda.
GraphQL server looks at the body of the request and handles the query
API Gateway will be a single endpoint of / graphql

merit

You can benefit from GraphQL (query flexibility, agility, performance improvements, PlayGround, automatic type information generation etc ...)
There is room for adding endpoints to API Gateway, so it can coexist with REST.

Demerit

Learning costs are higher because knowledge is less pervasive than REST. I think it is necessary to choose carefully because it will lead to education costs and transfer costs.
Receives the disadvantages of GraphQL (use of the library is almost mandatory on the client side, etc.)

Summary

Finally, I would like to compare and summarize each pattern item by item.

No need to consider the range of influence

Since the functions pattern (source code separation) separates both resources and sources, there are no dependencies, and functions can be added or modified without considering the range of influence. I think that there is a big advantage when developing with multiple members. Other patterns share the source code, so you need to consider a certain extent of influence.

Detailed policy management

If you have a need to set a policy for each Lambda function, you need to select the functions pattern. This is a security advantage, but it is also a disadvantage that makes management difficult.
In the case of GraphQL pattern, REST API can be added as needed, so if you really need this, you can cut it out and create Lambda and set the policy.

Use of common logic

If you can share the source code, you can use common logic, but not with the functions pattern (source code separation). You can use common logic with Layer, but I don't think it's a good option given the lack of completion and the cumbersome version control.

Easy to install

The functions pattern can be started immediately by using the SAM / Serverless Framework, but the other patterns are a little less easy to install because they require the settings of libraries and plugins.

Migrate to server

If there is a possibility of moving from serverless to EC2 / on-premise from the viewpoint of performance, it is desirable to have a configuration that can quickly remove resources. WebFramework patterns and GraphQL patterns can be moved to on-premise immediately by peeling off the wrapped library.

Low learning cost

Web Framework patterns that can be developed without being aware of Lambda will be more competitive in terms of learning costs. GraphQL is currently the most costly option to learn.

Ease of development

The functions pattern (source code separation) is difficult to develop because common logic is difficult to use. WebFramework patterns and GraphQL patterns can benefit from the framework and can be developed without any problems.

Ease of tracking error logs

When you want to follow the error log after deployment, the functions pattern in which CloudWatch is divided for each resource makes it easy to follow the error log.

Easy to deploy

The bottleneck of the functions pattern is that the SAM / Serverless Framework configuration file tends to be complicated. WebFramework patterns are grouped into proxies and GraphQL patterns are grouped into a single endpoint, so configuration files can be kept simple.

Finally

How was that?
The content of this article is basically an experience-based description, so it may not be comprehensive.
We would love to hear your opinions and reflect them in the content.
I would be very happy if you could comment on a story like "I developed this pattern, but it was good here, it was inconvenient here."

The strongest architecture to adopt in a startup.

ちぇん — Wed, 28 Oct 2020 17:27:40 +0000

Conclusion

ServerlessFramework is great
S3 hosting + CloudFront for the front end and Lambda@Edge for the SSR
Don't use RDS but DynamoDB as a database.
API is basically GraphQL, and you can easily add REST if you need it.

There is no absolute right answer to the architecture.

There is no absolute right answer for architecture.
This is because different products and phases have different requirements, and it is necessary to consider the appropriate architecture for them.

For example, the Tokyo Stock Exchange's high-speed trading system, which was recently closed for a day due to a failure, is an architecture that is fully allocated to stability and reliability requirements, distributing the load across 400 servers and localizing the impact of the failure by dividing the network.
Growth companies such as AWS have high scalability requirements and adopt a microservices architecture so that they can deploy new services without impacting the current application to keep innovating.

So let's consider what requirements are more important for startups.
Here is a ranking of the reasons why startups fail.

No. 1: there was no market need.
No. 2: Depletion of funds
No. 3: Inappropriate team composition
No. 4: Lost to the competition.
No. 5: Hard-to-use product

These are not all problems that can be solved by architecture, but you can see what requirements are needed.

No. 1: → Agility to change the specifications to meet customer feedback.
No. 2: → Cost optimization
No. 3: → Small team structure with as few specialists as possible
No. 4: → Increasing the speed of development to overtake the competition
No. 5: → Agility to increase the improvement cycle

We hypothesize that the requirements for startups are agility, cost optimization, small team, and speed of development.
We have examined the technical elements in this regard.

Technology Components

I've discussed how startups should adopt technology elements that excel in agility, cost optimization, small team, and speed of development.
I'm going to introduce the technology components that I think are superior in this regard.
I will explain in three stages: "front end", "database" and "back end (API)".

Frontend

Framework

There are three major front-end frameworks: React, Vue, and Angular.
In terms of "development speed" and "agility," I think typing in TypeScript is a must. The reason is that you can benefit from the completion and improve development efficiency by knowing what data to pass, and you can check for errors at compile time when you change the code due to specification changes.
In terms of compatibility with TypeScript, I think React is superior to the other two frameworks, and I think React should be adopted as a front-end framework.
Also, from the point of view of "speed of development" and "small team", I would recommend using Next.js rather than using bare React. This is because with Next.js, you can do things that are necessary but troublesome to implement with No Config. Specifically, routing and SSR (for SEO and SNS OGP).
From the above, Next.js (TypeScript) is recommended as a front-end framework.

Where to deploy the front end

The first places that come to mind for Next.js deployment are vercel, Netlify and Heroku.
These are good options because they are very easy to deploy and basically free to use.
However, there are always some functional limitations to the free quota, so if you're looking to scale, you'll want to build on AWS if possible.
With S3 hosting + CloudFront, you can use AWS free quota, and even if the free quota runs out, it's almost free (0.025 USD/GB for S3, 0.114 USD/10TB for CloudFront).
If you become a paid account for services such as vercel, you will have to pay a fixed cost, but with this configuration of AWS, it will be an on-demand billing, so we recommend S3 hosting + CloudFront in terms of "cost optimization".
By the way, since the free quota of vercel is also almost like unlimited, if you do not assume extreme scale, vercel is also totally good option.
I think that using a server such as EC2 or ECS as the deployment destination of the front end is out of the question from the point of view of "development speed" and "cost optimization".

Next.js SSR is done with Lambda@Edge.
Deploying this configuration is easy with ServerlessFramework with No Config.
https://github.com/serverless-nextjs/serverless-next.js

Database

RDS vs DynamoDB

In conclusion, I recommend you to choose DynamoDB without question.
To be more precise, RDS has to be used for complex data structures and access patterns, but in the initial phase, it is better to use DynamoDB and if it becomes complex, consider using RDS together.
From the point of view of cost optimization, Dynamo has a on-Demand option, while RDS charges by instance start-up time. Also, RDS+Lambda requires you to install RDS Proxy. There is also Aurora Serverless, but its cold start is critical.
Also, RDB has a dependency between tables, which makes it difficult to discard tables and causes migration and remaking of SQL.
In terms of development speed, Dynamo does not require management of database and is compatible with GraphQL, making it possible to increase development efficiency.

Designing DynamoDB

DynamoDB is recommended, but if you design DynamoDB like an RDB, you will get stuck, because DynamoDB doesn't allow joins, so you need to design your tables so that joins are not necessary.
RDB and NoSQL have completely different table design practices, so be sure to apply the initial learning curve here.

Backend(API)

REST vs GraphQL

We recommend GraphQL for agility, small team, and speed of development.
GraphQL transfers responsibility from the back end to the front end. It increases agility by not having to modify the API every time the UI is changed.
Also, if you write a REST API in Lambda, you will have to create as many Lambdas as there are endpoints (although there are ways not to do so), but GraphQL is a single endpoint, so you can keep it "small".
GraphQL is very easy to handle when using it from the front end, and although this is an experience, I feel that the front end development speed is higher than REST.

However, there are certain usecase for which REST is better suited. For example, file uploads require a little bit of work when using GraphQL. You can use REST endpoints in conjunction with an API Gateway in the same domain.

Deployment

Deploying the API Gateway + Lambda(GraphQL) + Lambda(REST) + DynamoDB configuration is easy with ServerlessFramework.
You can find templates for each language on here and try deploying it all the way through. You'll be surprised at how easy it is.
By the way, I use here after customizing it to make it easier to use.

About Certification Authorization

We use Cognito for authentication and authorization to implement login functions. If you are conscious of development speed, it may be faster to implement it yourself, but it's better to use a managed service because of the security implications.
This can also be added with ServerlessFramework.

Final Form.

In summary, the architecture is as shown in the above figure.

Using ServerlessFramework
S3 hosting + CloudFront for the front end and Lambda@Edge for the SSR
The database is DynamoDB, not RDS.
The API is basically GraphQL, you can easily add REST if needed.

I hope this will be helpful to those involved in startups.
Thank you.

Building "Neumorphism" iOS app

ちぇん — Thu, 02 Jul 2020 11:30:42 +0000

What is Neumorphism

Neumorphism is a style of design in which elements are pushed out or recessed in of the background.
It's starting to become popular in early 2020.

Cool 🥺.
I fell in love with it at first sight and decided to make some apps with Neumorphism design.
This is DDD (Design-Driven Development) (there is no such word).

I will create an AI recording app for talking in your sleep.
It's an app that records only sleep talks by applying voice recognition to sounds while you are sleeping.

Creating Neumorphism icon

In order to learn how to design Neumorphism, I'm going to start by building an app icon using Keynote.

1. Decide on a base color

I decided the base color to #C4D2E9.
Dye the background color with the base color.

2. Determine the color of the two shadows.

Change the brightness of the base color to determine the "light shadow" and "dark shadow".

light shadow: #ECF0F7
dark shadow: #0E1624

3. Place an object

Place the object you want to push out (or make a dent in).
In my case, I made it a balloon, like sleep talk.

4. Create an object with a dark shadow in the lower right corner

Erase the border and cast the dark shadow (#0E1624) that we decided on earlier in the lower right corner.

5. Create an object with a bright shadow in the upper left corner

Similarly, erase the border and cast the bright shadow (#0E1624) you just decided on in the upper left corner.

6. Stack the two objects

The two objects you made in steps 5 and 6 are stacked exactly on top of each other.
And then, oh my... I see...

7. Final touches to complete the icon.

I just put ZZZ on top, but this completes the icon.

Building Neumorphism app in Swift

Now that the icons are ready, everyone is waiting for you to implement the Neumorphism in Swift. Let's go!

Immediately I searched "Swift Neumorphism github".
And I found it! The library of our great predecessors!
https://github.com/hirokimu/EMTNeumorphicView

It's the best library for Neumorphism UIView.
Huh? Why not implement it full scratch? I do not.

Recording Screen

I used EMTNeumorphicView to create buttons.
The concave buttons are cute.

Playback Screen

It applies voice recognition to the recorded voice and displays only the sound that looks like a sleep mumble with the result of voice recognition.
It's not too noisy even if it's a list.

Source Code Release.

I'm not doing anything technically interesting, so I'll just publish the source code this time...
Code reviewers welcome! 🙇️
https://github.com/KitaharaMugiro/NegotoRecorder

"AI SleepTalk Recorder" is now available on the AppStore!

I also released it to the AppStore.
It's only 2$. Nothing is free. I'm planning to upgrade.
https://apps.apple.com/us/app/id1521147935

Increase your development success rate with a Lean start-up

ちぇん — Thu, 21 May 2020 11:17:09 +0000

personal development that fails.

I've made a number of products in the past as a personal development hobby.
I wanted a lot of users, and hoped to monetize them eventually, but unfortunately, they were only used by a small number of people for a short time, and we couldn't envision the future.
We tend to do things in personal development like "I had a good idea, so I just started making it" or "I just made it without a customer". I think it's a common mistake to end up with no one using your idea or customer because you didn't pack it in the first place.
That's fine in terms of developing a hobby or improving your skills, but if you have a desire to turn it into a business, you may need to rethink it.
If you're attacking an area that no one else sees as an issue, or if your solution isn't attractive enough for users to pay for, you're not going to be able to retain users, much less monetize them.
One of the methodologies for increasing the success rate of a product is the Lean Startup.
I would like to enumerate the things you should do before actually developing it with reference to it.

What is Lean Startup?

Lean means "waste-free and efficient," and Lean Startup is a methodology for eliminating the waste of time, effort, resources, and passion that comes with developing products and services that are worthless to customers in the minds of business owners. It is characterized by a minimum cost and a short cycle to find out the needs of the user by repeatedly testing the hypothesis.

What should you do before you develop a product?

1, Find a customer.

If the customer doesn't exist first, the service won't be used. Start by finding your customers. You need to find out where your customers are.
Decide on your target customer segment and make sure you can actually contact people in that segment, even if it's just a few people.

2, Find out what the customer has to do (JOB)

The customer has something to do (JOB). That's why needs arise because we are in need of something or want something.
Since the customer's needs are mostly in a non-verbal state, you need to explore them through interviews.
It's straightforward: "Is there anything you want? or "Will this solution I have in mind help you? If you ask, "What do you need?", you may not be able to properly understand your needs.
So the interview starts with understanding the client's **JOB.

What are the challenges?
Does the issue matter? Why do you think that?
How much opportunity loss, increased costs, stress, etc. are caused by it?
What solutions are you currently using to meet those challenges?
Is the solution appropriate? What other options do you have?
What is the satisfaction level of each solution? Hear more about the good and the bad.

By asking questions like the above, you can see what your customers need to do, what challenges they have, and what solutions they are currently using.
This is where we come up with solutions to solve the customer's problems.

3, Do a problem-solving fit

Even if you come up with a solution that solves a customer's problem, it is only a hypothesis as to whether it can actually solve the problem.
If it doesn't make the user want to actually pay to use it, then it's likely not solving the problem.
When you make an offer to a customer, you decide if they will agree to it or not.
The offer will be presented in three parts. First, a one word proposition of what the user is looking for, then a demo of mocks, videos, etc. that actually move the customer's journey forward, and finally a price model.
Repeat the offer presentation with user interviews to determine the actual MVP to be made.

4, Draw a business model

After deciding on the direction of the service to be developed, we will draw a business model.
There's a framework called Lean Canvas.

The Lean Canvas fills in the following nine items to get an overall picture of your business model.

Subject.
Customer segment 3、Unique value proposition
Solutions
Channel (how to approach the target)
Revenue stream
Cost structure
Key Indicators
Overwhelming superiority.

5. Actual production (product market fit)

Now that we've gotten this far, let's finally start developing the service!
This development phase is called Product Market Fit.
The purpose is the phase** of demonstrating whether a "service that customers are willing to pay for" actually produces money.
However, it is not always the case that if you don't actually generate money here, it is a failure. Some business models convert advertising costs and user-generated content into monetary value, which can only happen if you have a certain number of users.
Therefore, it is acceptable to use other alternative indicators. You can see if your service is sticking with your customers by, for example, conversion rates from landing pages to membership signups and user retention rates.

You don't need a lot of users to validate your business model. Therefore, there is no need for extensive publicity. When a new machine is installed in a factory, it is not suddenly put into full operation. Initially, we do a few tests and when we find that it works, we gradually increase the production volume.
Apparently, Facebook initially launched only at Harvard University instead of going global. By limiting the scope of their launch, they focused on improving the product and added more universities to use it one by one.
In this way, once we have confirmed the reproducibility of the product's market fit phase, we can expand our services in this way.

Finally.

I used to innocently think that if you create something interesting, you will get buzz and be a big success, so when I came across this Lean Startup methodology, it really opened my eyes.
Currently, I'm personally working with one designer and two engineers on a service for travelers "Travel Through", and I'm reflecting on the fact that I created the product at a stage where the business model and customer development were rather lax.
From now on, I would like to turn around, find the issues of the customers, and recreate the business model from scratch.
Let's do some fun personal development for reference!

A team with long experience in waterfall experienced agile development.

ちぇん — Sun, 05 Apr 2020 00:35:54 +0000

Summary

I works as a consultant and coached a team with long experience in waterfall to develop a product by agile. I lectured some agile practices and I asked what they thought about them.

Practices which I lectured

Sprint
Task management with Kanban
Test Driven Development
Pair Programming
Refactoring
Estimation by story points

Impressions of introducing Sprint

In the first sprint, we only focused on the most valuable feature so we designed it and coded it immediately. I thought it was good that the span of PLAN to DO was short. Because in the watarfall case we cannot DO(coding) until we PLAN(design) everything and this is too slow to verify that the product is really valuable.

Impressions of introducing Task management with Kanban

Task size was smaller than we do in the watarfall and I was glad I could concentrate on the small task. I didn't need to see other modules or functions.
I could see who do what, so I didn't need to worry about progress.

Impressions of introducing Test Driven Development

It was very interesting to develop product gradually.
Test driven development seems to be incompatible when test specifications and test reports are requested as deliverables
I think it's very interesting that the test behaves like a specification, so I'd like to actively incorporate it if I can get the customer's understanding.

Impressions of introducing Pair Programming

Troubles are solved immediately and it is easy to do (less time spent worrying alone)
I spend more time thinking or doing research than coding, so I thought pair programming does not decrease productivity.
It seems to be incompatible with man-month calculation.
There is no atmosphere of coding with people(normally alone) in the current position, so introduction of pair programming seems to have psychological obstacles.

Impressions of introducing Refactoring

The end of production means the end of the project in watarfall, so there's not much motivation for refactoring.
Code doesn't have to be pretty. If it move, OK!
But I know I should code cleanly.
Because specification of product can change every weeks in agile development, it's important to keep the code base so that changes can be accepted.

Impressions of introducing Estimation by story points

Accuracy was higher than estimated by feeling
I was able to experience that the accuracy improved with each sprint

Conclusion

Waterfall development is vulnerable to change, and programmers at the site are aware of it.
The importance of doing things like "I don't know what the user wants. Let's make a hypothesis and receive feedback to grow the product" is increasing in this age.
In doing so, the above agile practices may be helpful.

I want your comment.

I am Japanese and in Japan almost all of development is waterfall.
I work as a consultant to change their mind, skill, or company system to move to agile from waterfall.
I want to know about your country case.

Why don't we take in DDD to interview coding test.

ちぇん — Fri, 03 Jan 2020 20:29:55 +0000

I always feels the code of interview tests is not readable.
The shorten variable names, all logic packed in one method, etc. They are forbidden in real life coding but is it really okay in interview?

Watch example from leetcode.
https://leetcode.com/problems/longest-substring-without-repeating-characters/

The question is like this.

Given a string, find the length of the longest substring without repeating characters.

Example 1:

Input: "abcabcbb"
Output: 3 
Explanation: The answer is "abc", with the length of 3.

And the example answer is like this.

def lengthOfLongestSubstring(self, s):
    str_list = []
    max_length = 0
    for x in s:
        if x in str_list:
            str_list = str_list[str_list.index(x)+1:]
        str_list.append(x)    
        max_length = max(max_length, len(str_list))
    return max_length

Yeah, it's a short method and not difficult to understand but not perfect.
If you take in DDD and Value Object, it can be more readable.
Like this.

class Character : 
    def __init__(self , c:str) : 
        self.c = c

    def getValue(self) -> str : 
        return self.c

    def same(self , c) : 
        return self.c == c.c

class SubString : 
    def __init__(self) : 
        self.queue = []
        self.memo = {}

    def add(self, c:Character) :
        self.queue.append(c)
        self.memo[c.getValue()] = True

    def pop(self) -> Character : 
        c = self.queue.pop(0)
        self.memo[c.getValue()] = False
        return c

    def popUntil(self, c:Character) :
        popped = self.pop()
        while not popped.same(c) : 
            popped = self.pop()

    def contains(self, c:Character) : 
        return self.memo.get(c.getValue()) or False

    def length(self) : 
        return len(self.queue)


class Solution:
    def lengthOfLongestSubstring(self, s: str) -> int:
        subString = SubString()
        maxLength = 0
        for c in s : 
            character = Character(c)
            if subString.contains(character) : 
                subString.popUntil(character)
            subString.add(character)
            maxLength = max(maxLength , subString.length())
        return maxLength

wow it got longer than previous one.
However it's easier to understand the coder thought, is it?
Yeah, I know that time is limited in interview but I think the most important thing is to convey your thinking process to people, then try to take in DDD and you can express your thought more easily.

Three layers of productivity and my recommends

ちぇん — Mon, 11 Nov 2019 21:15:58 +0000

I think there are three layers in the productivity.

The first one is personal productivity, the second one is team productivity, and the last layer is the architecture(or organization) productivity.

Personal Productivity

My recommends for boosting personal productivity in coding are TDD, knowing data structure and algorithm, and design pattern.
TDD stands for Test Driven Development and it improve my code and speed.
Knowing data structure, especially hash map, reduce my time for problem resolution.
And design pattern is applicable through any platform or any framework. Listener pattern can be used in mobile development, web development, and simple application anywhere.

Team Productivity

Agile or Scrum is for boosting team productivity.
Kanban board is super useful for task management.
Retrospective makes us look back our process and improve it.

Architecture Productivity

Micro Service is the best architecture for big products.
Many team can work in autonomous with freedom and responsibility.
Each team can use any technology and any programming language for the specific problem they want to solve.
They can innovate small.
It also reduce communication overhead.

What is the most import factor to be a high salary engineer?

ちぇん — Sat, 12 Oct 2019 19:19:42 +0000

Good portfolio to show on job interviews?
Broad knowledge of data structure and algorithm?
Job Experience? What kind of job experience is needed?