Rain slicked the neon-streaked streets, painting the city in shimmering, blurred strokes of light. Inside the Google Shibuya office, a profound silence hummed, broken only by the distant thrum of the metropolis. I was an intruder, a ghost in the machine, my presence a violation of the digital sanctuary.

For months, I’d been chasing whispers—coordinates hidden in data streams, fragments of code echoing in the vastness of machine learning algorithms, cryptic messages tucked away like digital breadcrumbs. Each clue led me to a new, seemingly insignificant object, unremarkable on its own, but together, forming a mosaic of a larger, unfolding mystery. This time, however, the stakes felt different.

The latest directive was a minimalist enigma: "Find the stone that remembers the light." It had led me to this glass and steel fortress.

I found the indoor garden on the fifth floor, a tranquil oasis designed for tech-weary minds. A pristine rectangle of fine sand, a scattering of elegant bamboo stalks, and a meticulous arrangement of smooth river stones. They all looked identical, dozens of muted gray stones, perfectly rounded, perfectly balanced, perfectly ordinary.

But as I stepped closer, a subtle shift occurred. It wasn't visual; it was a visceral pull, a quiet hum against my skin, as if one of them was calling to me. A silent gaze met mine.

I crouched, my fingers tracing the cool, smooth surface of the third stone from the edge. It felt alive, radiating a faint, almost imperceptible tremor, like distant static. Just a stone among stones, yet a flicker of something ancient and potent passed from its surface to my fingertips. Without a moment's hesitation, I slipped it into my pocket.

That's when the world fractured.

A strident, digital shriek tore through the silence, followed by the pulsating wash of crimson light flooding the hallway.

A calm, almost unnervingly polite voice echoed through the intercom system: "Security alert. Please remain where you are."

I didn't.

Adrenaline surged, a fierce current propelling me through glass-walled corridors and chrome pathways. My footsteps, usually an echo in the quiet office, were swallowed by the piercing wail of the siren. The elevator was locked down, a red X glowing ominously, so I plunged into the stairwell, my heart hammering a frantic rhythm against my ribs. I half-expected to hear shouts, to feel the grip of a security guard, but there was only the siren's relentless cry.

Outside, the rain intensified, blurring the city lights into impressionistic streaks across the glistening pavement. I pulled out the stone. It looked utterly unremarkable—just like the others, no visible glow, no discernible hum. No proof of the clandestine energy that had coursed through it.

But then, my phone screen flickered to life. A single message, from an unknown sender, materialized:

"3 of 9. Memory secured. Proceed."

I stood there, the rain soaking my sleeve, the stone heavy in my palm, and for the first time, a chilling question surfaced: Am I truly collecting these fragments for myself, or am I merely a puppet, a conduit for something far older and more formidable, something that watches through my eyes?

Creating an AI-powered code review agent that integrates with GitLab can significantly streamline the development process. By leveraging LangChain, the Model Context Protocol (MCP), and Retrieval-Augmented Generation (RAG), we can build an agent capable of retrieving, analyzing, and providing feedback on code changes.This guide will walk you through setting up such an agent, complete with sample code snippets.

🧠 Overview

Our AI code review agent will:

Connect to GitLab: Utilize an MCP server to interact with GitLab repositories.
Index Source Code: Employ RAG to embed and index the codebase for efficient retrieval.
Analyze Merge Requests: Automatically fetch and review merge requests, providing actionable feedback.

🛠️ Prerequisites

Before we begin, ensure you have the following:

• Python 3.8+- Node.js (v16+)

• GitLab Personal Access Token

• GitLab MCP Server: A server that exposes GitLab functionalities via MCP. Refer to GitLab MCP Server for setup instructions

• Required Python Packages

pip install langchain faiss-cpu openai mcp-use

💡Step-by-Step: Building the Agent

Let's break down the development process.

🧱 Indexing the Codebase with RAG

Retrieval-Augmented Generation (RAG) enhances the agent's ability to provide contextually relevant feedback by retrieving pertinent information from the codebase.

Load and Split the Codebase:

from langchain_community.document_loaders.generic import GenericLoader
from langchain_community.document_loaders.parsers import LanguageParser
from langchain.text_splitter import RecursiveCharacterTextSplitter

# Load all code files from the local folder
loader = GenericLoader.from_filesystem(
    "./source",
    glob="**/*",
    suffixes=[".swift"],
    parser=LanguageParser()
)
documents = loader.load()

# Split documents into manageable chunks
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,      # Max characters per chunk
    chunk_overlap=200,    # Overlap between chunks to maintain context
    length_function=len,
    add_start_index=True, # Add metadata about the start index of the chunk
)
chunks = text_splitter.split_documents(documents)

Generate Embeddings and Store in Vector Database:

from langchain_huggingface import HuggingFaceEmbeddings
from langchain_chroma import Chroma

# Initialize the embedding model
embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2")

# Check if the vector store already exists to create or load
persist_directory = "./chroma"
if os.path.exists(persist_directory) and os.listdir(persist_directory):
    print(f"Loading existing Chroma DB from {persist_directory}")
    vectorstore = Chroma(persist_directory=persist_directory, embedding_function=embeddings)
else:
    # Ensure the persist directory exists
    os.makedirs(persist_directory, exist_ok=True)
    vectorstore = Chroma.from_documents(
        documents=chunks,
        embedding=embeddings,
        persist_directory=persist_directory
    )
    vectorstore.persist()
    print("Chroma DB created and persisted.")

This setup allows the agent to retrieve relevant code snippets when analyzing merge requests.

Define the RAG Retrieval Tool

Create a custom tool that utilizes the vector store to retrieve relevant code snippets:

from langchain.agents import Tool

def retrieve_code_snippets(query):
    # Retrieve relevant documents based on the query
    docs = vectorstore.similarity_search(query)
    # Combine the content of the documents into a single string
    return "\n".join([doc.page_content for doc in docs])

# Define the tool
rag_tool = Tool(
    name="RetrieveCodeSnippets",
    func=retrieve_code_snippets,
    description="Retrieves relevant code snippets based on a query."
)

Hint: We can use the RetrievalQA to let llm communicate directly without RAG tool.

def setup_rag_chain(vectorstore):
    """
    Sets up the Retrieval Augmented Generation (RAG) chain.
    This chain takes a query, retrieves relevant documents from the vector store,
    and then passes them to the LLM to generate an answer.
    """
    print("Setting up RAG chain...")
    llm = OllamaLLM(model="deepseek-r1:7b") # local llm

    # Define a custom prompt for the LLM
    # This prompt guides the LLM on how to use the retrieved context
    custom_prompt_template = """Use the following pieces of context to answer the user's question.
If you don't know the answer, just say that you don't know, don't try to make up an answer.
Keep the answer concise and relevant to the codebase.

Context:
{context}

Question:
{question}

Helpful Answer:"""
    CUSTOM_PROMPT = PromptTemplate(
        template=custom_prompt_template,
        input_variables=["context", "question"]
    )

    # Create the RetrievalQA chain
    # 'stuff' chain type puts all retrieved documents into the prompt
    qa_chain = RetrievalQA.from_chain_type(
        llm=llm,
        chain_type="stuff",
        retriever=vectorstore.as_retriever(search_kwargs={"k": 5}), # Retrieve top 5 relevant documents
        return_source_documents=True, # Return the documents that were used to generate the answer
        chain_type_kwargs={"prompt": CUSTOM_PROMPT}
    )
    print("RAG chain setup complete.")
    return qa_chain
    
# Usage
result = qa_chain({"query": query})

🛠️ Setting Up the Agent with mcp-use

To streamline the integration of GitLab tools into your LangChain agent, you can utilize the mcp-use library. This library simplifies the process of connecting LangChain-compatible LLMs with MCP servers, allowing for seamless tool integration without manual definitions.

Clone and build Gitlab MCP server:

Your system needs NodeJS to build and start the server.

git clone https://github.com/rifqi96/mcp-gitlab.git
cd mcp-gitlab
npm install
npm run build

After building the source code you can find the index.js in the build folder and use to start the local mcp server and connect with client.

Initialize the MCP Client:

Set up the MCP client to connect to your GitLab MCP server:

from mcp_use import MCPClient

# Init the client with local server built source configuration
config = {
  "mcpServers": {
    "gitlab": {
      "command": "node",
      "args": ["/path/to/mcp-gitlab/build/index.js"],
      "env": {
        "GITLAB_API_TOKEN": "YOUR_GITLAB_API_TOKEN",
        "GITLAB_API_URL": "https://gitlab.com/api/v4"
      }
    }
  }
}

client = MCPClient.from_dict(config)

Load Tools from the MCP Server:

Retrieve the available tools from the connected MCP server:

mcp_tools = client.load_tools()

Integrate Tools into Your Agent:

Pass the loaded tools from RAG and MCP server to your LangChain agent:

from langchain.agents import initialize_agent
from langchain.llms import OpenAI

# Initialize your LLM
llm = OpenAI(temperature=0)

all_tools = mcp_tools + [rag_tool]

# Create the agent with the loaded tools
agent = initialize_agent(all_tools, llm, agent="cool-ai-reviewer", verbose=True)

Use the Agent:

Now, you can prompt your agent to perform tasks:

# Example prompt to review a merge request
prompt = "Review merge request #42 and provide feedback on code quality and potential issues."

# Run the agent with the prompt
agent.run(prompt)

By leveraging the mcp-use library and RAG, you can efficiently integrate GitLab functionalities into your LangChain agent. The agent will utilize the tools to fetch merge request details and retrieve relevant code snippets, enabling it to provide comprehensive feedback. This approach enhances scalability and maintainability, especially when dealing with multiple tools or MCP servers.

🧪 Testing the Agent

To ensure the agent functions correctly:

Submit a Merge Request: Create a new merge request in your GitLab repository.

Run the Agent: Use the agent to review the merge request by providing the appropriate prompt.

Evaluate Feedback: Assess the feedback provided by the agent for accuracy and usefulness.

🚀 Conclusion

By integrating LangChain with GitLab via an MCP server and employing RAG for code indexing, we've built a powerful AI agent capable of automating code reviews. This setup not only saves time but also enhances code quality by providing consistent and thorough feedback.

Feel free to expand upon this foundation by adding more tools, improving the embedding model, or integrating with other services to further enhance the agent's capabilities.

Here’s a comprehensive guide to securing mobile applications, covering key threats, best practices, and strategies for developers.

Understanding Mobile App Security Threats

Before implementing security measures, it’s essential to recognize the common threats mobile apps face:

1. Data Breaches: Unauthorized access to sensitive information, such as personal data, financial details, or login credentials.
2. Malware: Malicious software designed to exploit vulnerabilities in apps, leading to unauthorized control or data theft.
3. Man-in-the-Middle (MitM) Attacks: Interception of data transmitted between the app and server, compromising sensitive information.
4. Reverse Engineering: Attackers decompile apps to uncover vulnerabilities or steal intellectual property.
5. Insecure Data Storage: Storing sensitive data in plain text or improperly secured databases, making it vulnerable to attacks.
6. Weak Authentication: Poorly implemented authentication mechanisms can allow unauthorized access.

Best Practices for Mobile App Security

1. Secure Code Practices

• Minimize Vulnerabilities: Conduct regular code reviews and use static analysis tools to identify potential issues.
• Obfuscation and Encryption: Obfuscate your code to make reverse engineering difficult and encrypt sensitive logic.
• Update Regularly: Patch known vulnerabilities promptly to stay ahead of emerging threats.

2. Implement Robust Authentication

• Use multi-factor authentication (MFA) to enhance security.
• Employ strong password policies and consider biometric authentication methods like fingerprint or facial recognition.

3. Encrypt Data

• Encrypt data both at rest and in transit using protocols like HTTPS and AES.
• Avoid storing sensitive data locally unless absolutely necessary, and if stored, use secure containers or encrypted databases.

4. Secure APIs

• Authenticate and authorize API requests to prevent unauthorized access.
• Limit API access to trusted endpoints and employ rate limiting to prevent abuse.

5. Protect Against Reverse Engineering

• Use tools like ProGuard for Android and obfuscation techniques for iOS.
• Sign your app with a certificate to ensure its integrity.

6. Conduct Regular Security Testing

• Perform penetration testing to identify vulnerabilities from an attacker’s perspective.
• Use automated tools for dynamic and static application security testing (DAST and SAST).

7. Secure Third-Party Libraries

• Ensure third-party libraries are updated and sourced from reputable providers.
• Regularly audit libraries for vulnerabilities and remove unused dependencies.

8. User Education

• Educate users about secure practices, such as recognizing phishing attempts and avoiding untrusted networks.
• Clearly communicate the importance of app updates for maintaining security.

Strategies for Ongoing Security Maintenance

Adopt a DevSecOps Approach

• Integrate security into every stage of the development lifecycle.
• Use tools and automation to enforce security standards consistently.

Monitor and Respond to Threats

• Implement monitoring tools to detect unusual activity in real-time.
• Have an incident response plan ready to address potential breaches swiftly.

Compliance and Regulations

• Ensure compliance with data protection laws like GDPR, HIPAA, or CCPA.
• Use security standards like OWASP’s Mobile Top 10 as a guideline.

Secure App Distribution

• Distribute apps through official app stores to reduce the risk of tampering.
• Use app store protections like Google Play Protect or Apple’s security reviews.

Conclusion

Security is not a one-time effort but an ongoing process requiring vigilance and proactive measures. By following these best practices and strategies, developers can create secure mobile applications that protect user data and build trust with their audience.

As the mobile app landscape evolves, staying informed about emerging threats and security advancements is key to maintaining a robust defense. Prioritize security at every stage of development to ensure your app’s success and sustainability in an increasingly connected world.

1. Design:
   Does the code change make senses? is it a good time to add? how does it integrate with our current code base or system?
   
   
2. Functionality
   Determine the users of this code change: both end-users (feature impact) and developer (future use, future enhancement?)
   Ask for a demo/UI if need to understand the reason
   Introduce a race condition or deadlocks?
   
   
3. Complexity
   Functions are too complex?
   Classes are too heavy?
   “Too complex” usually means “can’t be understood quickly by code readers.” It can also mean “developers are likely to introduce bugs when they try to call or modify this code.”
   Over-engineering: code is more generic than it needs to be, solving a future problem? future problems should be solved when it arrives not the time of PR.
   
   
4. Test
   Ask for Unit tests, integration tests, end-to-end tests
   Test should never test itself
   Tests are code so that they are need to be easily maintained
   
   
5. Naming
   Naming is hard, should pick a good name: descriptive and describe correctly the purpose
   
   
6. Comments
   Comment WHY not WHAT to do
   Check the necessary of the comments
   Need to be a clear and understandable ENGLISH (don't use Japanese)
   Comments are different from documentation
   
   
7. Styles
   Follow Swift Lint rules https://realm.github.io/SwiftLint/rule-directory.html
   Run SonarQube before making the PR, always check SonarQube results after PR made
   
   
8. Documentation
   Should always be updated with the code
   Delete if code is deleted
   Update README in case new code violates it
   
   
9. Every line
   It's a must to go through every line of code that have been assigned to you.
   Some codes are auto generated, but never skip human-written code.
   For large code base, break into parts to review, note in comment for the part that reviewed or mark reviewed using Gitlab interface then can continue at another time.
   Ask for clarification if any codes slow down your review.
   
   
10. Context
    Sometimes need to have a broader context to tell code changes make sense: for example several lines are changes, but need to read whole class to decide correctly.
    Don’t accept PRs that degrade the code health of the system
    
    
11. Good thing
    If see something nice in the PR, tell the developer. Code reviews often emphasize on mistakes, but should offer encouragement and appreciation for good practices.

Based on https://google.github.io/eng-practices/review/reviewer/looking-for.html

Introduction

Are you tired of the manual and time-consuming process of deploying your iOS applications? Look no further. With the power of GitHub Actions, deploying iOS apps has never been easier. By automating the building, testing, and deployment tasks, you can save time and eliminate human error.

In this blog post, we will explore how to deploy iOS applications using GitHub Actions. I'll walk through the essential elements you need to prepare, such as setting up a build machine, managing certificates and provisioning profiles. Additionally, we'll dive into the concept of environment variables and how they can simplify the configuration process.

Preparation

A build machine with Installed Xcode

To build and package an iOS application, you need a dedicated build machine. Set up your correct version of Xcode. I would recommend to use Xcodes tool to manage multiples XCode versions on your build machine.
https://github.com/XcodesOrg/xcodes

Code signing certificate

I assume you know how to create/store/export a deployment certificate. Our certificate .p12 will be encoded to base64 string and stored as environment variables (please find detail in next segment). Then we create a bash script install_certificate.sh to

• Create new keychain.
• Install the certificate to the keychain.
• Unlock the keychain to allow xcode access it to use the cert when exporting ipa.

Here is the content of the sript

#!/usr/bin/env sh

CERTIFICATE_P12=certificate.p12

# Decoding the base 64 cert and write it to a file
echo $CERT_BASE64 | base64 --decode > $CERTIFICATE_P12

# Creating new keychain with a password
security create-keychain -p $BUILD_KEY_CHAIN_PASSWORD $BUILD_KEY_CHAIN_NAME
# Setting the keychain as default
security list-keychain -s $BUILD_KEY_CHAIN_NAME
security default-keychain -s $BUILD_KEY_CHAIN_NAME
# Unlock the keychain
security unlock-keychain -p $BUILD_KEY_CHAIN_PASSWORD $BUILD_KEY_CHAIN_NAME
# start manipulate it
security set-keychain-settings $BUILD_KEY_CHAIN_NAME
# import the cert content, $2 is the certificate password
security import $CERTIFICATE_P12 -k $BUILD_KEY_CHAIN_NAME -P $CERT_PASSWORD -T /usr/bin/codesign;

# we allow codesign to use the keychain above
# codesign is the tool that xcode uses to sign our app
# https://stackoverflow.com/questions/39868578/security-codesign-in-sierra-keychain-ignores-access-control-settings-and-ui-p
security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k $BUILD_KEY_CHAIN_PASSWORD $BUILD_KEY_CHAIN_NAME

# Then just remove the file
rm -fr *.p12

This bash script will be called like

chmod +x install_profile.sh && ./install_certificate.sh

Provisioning profile

It's simpler with provisioning profile. We just need to write it to the file with correct name in a correct folder. Let make another bash script install_profile.sh

PROFILE_FILE=$1.mobileprovision

echo $PROVISIONING_BASE64 | base64 --decode > $PROFILE_FILE

cp ${PROFILE_FILE} "$HOME/Library/MobileDevice/Provisioning Profiles/$1.mobileprovision"

rm -fr *.mobileprovision

Nice, really easy to understand.

So your machine is ready to build because it has the cert & provisioning. From next steps, I will share what i achieve to automate the whole process.

Fastlane script

I will give you an example of the lane I made, please adjust depends on your team need.

desc "PROD Build and upload to AppStore if need"
lane :prod_appstore do |options|
  $version = options[:version] || get_version_number(xcodeproj: ENV["PROJECT_IDENTIFIER"], target: ENV["BUILD_TARGET"])
  $build = options[:build] || get_build_number(xcodeproj: ENV["PROJECT_IDENTIFIER"])

  prepare(
    plist: ENV["PLIST_FILE_NAME"], 
    version: $version, 
    build: $build, 
    team_id: ENV["APP_STORE_TEAM_ID"], 
    code_sign: ENV["CODE_SIGN_IDENTITY_NAME"], 
    provisioning: ENV["PROVISIONING_NAME"], 
    bundle_id: ENV["APP_BUNDLE_ID"],
    xcode_version: options[:xcode_version]
  )
  gym(
    scheme: scheme,
    export_method: "app-store",
    export_team_id: ENV["APP_STORE_TEAM_ID"],
    export_options: {
      provisioningProfiles: {
        ENV["APP_BUNDLE_ID"] => ENV["PROVISIONING_NAME"]
      },
      manageAppVersionAndBuildNumber: false
    },
    codesigning_identity: ENV["CODE_SIGN_IDENTITY_NAME"],
    clean: true,
    output_directory: "./builds",
    skip_build_archive: false,
    output_name: "just-a-name.ipa"
  )
  verify_build(
    provisioning_type: "distribution",
    bundle_identifier: ENV["APP_BUNDLE_ID"],
    team_identifier: ENV["APP_STORE_TEAM_ID"]
  )
end

def prepare(plist:, version:, build:, team_id:, code_sign:, provisioning:, bundle_id:, xcode_version:)
  puts "Configure Xcode and Project"
  if xcode_version
    xcversion(version: xcode_version)
  end

  ensure_git_status_clean
  increment_version_number(version_number: version)
  increment_build_number(build_number: build)

  update_code_signing_settings(
    use_automatic_signing: false,
    targets: [ENV["BUILD_TARGET"]],
    path: ENV["PROJECT_IDENTIFIER"],
    team_id: team_id,
    code_sign_identity: code_sign, 
    profile_name: provisioning,
  )

  update_app_identifier(
    plist_path: plist,
    app_identifier: bundle_id
  )

  update_project_team(
    path: ENV["PROJECT_IDENTIFIER"],
    targets: [ENV["BUILD_TARGET"]],
    teamid: team_id
  )

  cocoapods(clean_install: true)
end

Fastlane upload to App Store

This is sample steps in fastlane.

api_key = app_store_connect_api_key(
  key_id: ENV["APP_STORE_KEY_ID"],
  issuer_id: ENV["APP_STORE_ISSUER_ID"],
  key_content: ENV["APP_STORE_KEY"],
  is_key_content_base64: true,
  duration: 1200, # optional (maximum 1200)
  in_house: false
)

upload_to_testflight(
  ipa: "./builds/just-a-name.ipa", 
  skip_submission: true,
  skip_waiting_for_build_processing: true,
  api_key: api_key
)
end

I wrote details about some ways to upload in this blog
https://www.hapq.me/two-ways-to-upload-ipa-to-testflight-with-fastlane/

Environment Variables

This is the thing I missed for long time in my whole career. I found out these variables are live inside a terminal session. We can store it by running this command

export MY_FUTURE_USE_VARIABLE=Hello

then when need to use, add a dollar sign before the name

echo $MY_FUTURE_USE_VARIABLE

Really simple but i don't know why I missed this stuff.

In any CI/CD tools such as Gitlab, Jenkins, Github action... there're always predefined environment variables that tell you about the job, the pull request, the machine etc.... You can access it anywhere anytime you want.
Gitlab CI shared details of them: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

Github action & Gitlab CI

please wait for part 2 of this serie.

TBRA presents a superb opportunity in my local market for local bicycle providers for the 2020 Olympics. There are no direct competitors for now. Revenues are expected as 330.000$ for first year and will keep stable as 500.000$ for each year later.

BUSINESS DESCRIPTION
Product:
TBRA is a mobile application for travelers to find nearby bicycle renting places. They can go directly by foot and rent the bike they like.

Manage and operation:
TBRA will have zero managers and 5 employees. TBRA team will maintain systems, connect bicycle renting vendors, and do SEO for the application.

MARKETING
Market research
Opportunity: TBRA presents an exciting opportunity in my local market with travelers who come to Tokyo in 2021 to support their favorite Olympic sport teams. For the first year, we will spend money to claim users and get connections with local bike vendors.

On Friday, July 23, 2021, the 2020 Olympics will be held in Tokyo. All people around the world will go to Japan and the need for bike services will increase. According to simple statistics of the 2016 Olympics in Rio De Janeiro, around 6.6 million travelers arrived in Brazil.

“A total 6.6 million international travelers visited Brazil last year, the tourism ministry said, 4.8 percent higher than the year before.” - VOA news

If we can get 5% of these tourists to use our applications, taking 1$ per each trip, our revenue totally will be 330.000$.

COMPETITIVE ANALYSIS:
These are some good applications I found: NextBike, oBike-Stationless. One of them has around 1M downloads but they don’t have connections/vendors in Tokyo for now. We can research their business flow/application flow to contribute to our business model.

FINANCIALS:
StartUp Costs:

• Application development : backend, map service, mobile app. Salary for developers: 3 developers * 50k$ = 150k$
• Station: Zero cost, for the first year, we can connect with existing local vendors.
• Bike: Zero costs, from vendors, we take a small fee for each user’s ride.
• Application Infrastructure: 10k$
• Vendors connection: 40k$
• Risks: problem handle 30k$

Total cost: 230.000$

Second years and laters:
Sales & Revenue Projections:
1st year: 330.000$
2nd year: 500.000$
3rd year: 500.000$
Revenues are expected to increase from 330k to 500k in three years.

Costs Projections:
Startup Costs: 230.000$
2nd year: 300.000$
3rd year: 200.000$
Costs are expected to increase from 230k to 300k and decrease to 200k in the first 3 years.

Profit Statement Expected:
1st year: 100.000$
2nd year: 200.000$
3rd year: 300.000$
Income is expected to go up from 100k to 300k in three years.

Well it's the past, but when looking back I feel it's really satisfying. At least i put something on paper. Today I've just asked ChatGPT for improvements, it gave mesome ideas?

Clarify the value proposition: While it's clear that TBRA will allow travelers to easily find and rent bicycles, it's not clear what the benefits are for the local bike vendors. What incentive do they have to partner with TBRA? You may want to consider offering a revenue-sharing model or other benefits to encourage vendor participation.

Conduct more market research: While it's helpful to have statistics on the number of travelers who visited Brazil during the 2016 Olympics, it's important to gather more detailed information about the target market in Tokyo. For example, what are the demographics of travelers who are likely to use TBRA? What are their preferences and pain points? This information will help you refine your marketing and product strategies.

Develop a more detailed marketing plan: It's great to have a goal of getting 5% of Olympic tourists to use TBRA, but how exactly do you plan to achieve this? Consider using a mix of online advertising, social media, influencer marketing, and partnerships with travel agencies or hotels to increase awareness and drive downloads.

Consider the costs of ongoing maintenance and support: While your startup costs seem reasonable, it's important to factor in the ongoing costs of maintaining and updating the app, providing customer support, and managing relationships with vendors. These costs may be higher than you anticipate, so it's important to plan accordingly.

Explore potential partnerships: In addition to partnering with local bike vendors, consider other potential partners who could help you reach your target market. For example, you might partner with a tourism board or travel app to promote TBRA to travelers.

Overall, your business idea has potential, but it's important to do more research and planning to ensure that it is successful. Good luck!

Potential idea? I'm too bad, has no courage, no brave enough to challenge myself?

Years of research later, the Martians discovered that the Golden Element had the ability to fuel their spaceships, making their interplanetary travels faster and easier. Excited by this new discovery, they built a magnificent spaceship entirely out of the Golden Element, and set out to explore the universe.

As the Martians traveled from planet to planet, they eventually came across a small, blue planet with abundant resources. They decided to make it their new home, and they established a colony on the planet, which they named Earth. Over time, the Martians thrived on Earth and evolved into the human race.

However, as the human race progressed, they began to forget their origins and the significance of the Golden Element. But a small group of humans, who had kept the knowledge passed down from their Martian ancestors, formed a secret society to collect the Golden Element and rebuild the spaceship to return to their ancestral home on Mars.

Despite facing challenges and opposition, the society persevered in their mission. They traveled far and wide, collecting every scrap of the Golden Element they could find, refining it and using it to rebuild the magnificent spaceship. And after many long years of hard work, the spaceship was finally complete.

The day finally arrived for the humans to embark on their journey back to Mars. As they lifted off from the Earth and set course for their ancestral home, they felt a sense of pride and belonging. They were finally going back to where they came from, to reclaim their heritage and build a new civilization on Mars.

And so, the story of the human race and their journey back to their ancestral home on Mars comes full circle. A tale of determination, perseverance, and the power of knowledge passed down from generation to generation."

This story is written by chatGPT based on my idea. Images are generated by MidJourney.

Client-side load balancing is a method of distributing network traffic across multiple servers by using a client device to determine the most efficient server to handle a request. While this method can provide some benefits, such as reducing the load on a single server and improving overall performance, it also has several disadvantages that should be considered before implementing it in a network.

My team is implementing it and I don't like beacause of some drawbacks.

Networking Complexity increasing

One major disadvantage of client load balancing is that it can increase the complexity of a network.

In client-side load balancing, the client device is responsible for determining the most efficient server to handle a request, it must have knowledge of all available servers and their current load. This requires significant configuration and maintenance, which can be time-consuming and prone to errors. For example, the client device needs to be configured with the IP addresses and ports of all available servers, and it must also be updated with new server information as servers are added or removed from the network.

Additionally, client-side load balancing can also increase the complexity of network troubleshooting and monitoring. As the client device is responsible for determining the server to handle a request, it can be difficult to determine the root cause of issues that arise. It can be challenging to identify the specific server that is causing problems, and it can also be difficult to determine if the issue is with the client device or with one of the servers.

Furthermore, client-side load balancing can also create additional complexity when it comes to deploying updates and new features. Since the client device is responsible for determining the server to handle a request, it must be updated and configured with new features and updates at the same time as the servers. This can be difficult to coordinate and can create additional downtime for users.

Security Risks

Another disadvantage of client load balancing is that it can increase the risk of security breaches. Since the client device is responsible for determining the server to handle a request, it must have access to sensitive information such as server IP addresses and load data. This can make the client device a prime target for hackers, who can use this information to launch attacks on the network.

Dataloss

Another problem is that client load balancing can increase the risk of data loss. Since client devices are not aware of the state of the servers, they may send requests to servers that are down or undergoing maintenance. This can result in data loss or corruption, which can be costly and time-consuming to recover from.

Additionally, client-side load balancing can also make it more difficult to implement security measures such as firewalls and SSL offloading. Since the client device is responsible for determining the server to handle a request, it must have access to all servers on the network. This can make it difficult to implement security measures that are specific to a single server, and can also make it more difficult to monitor and troubleshoot security issues.

Bottleneck

Additionally, client load balancing can create bottlenecks. If the client is unable to handle the load of the balancing process, it can become overwhelmed and slow down, creating a bottleneck in the network. This can reduce the overall performance of the network and create a poor user experience.

In conclusion, while client load balancing can provide some benefits, it also has several disadvantages that should be considered before implementing it in a network. These include increased complexity, security risks, data loss, and bottleneck problems. It's important to weigh the pros and cons of this method before implementing it, and to consider alternative solutions, such as server-side load balancing, which may be more appropriate for certain environments.

This blog powered by ChatGPT

Introduction to view modifiers in SwiftUI

SwiftUI is a powerful framework for building user interfaces on Apple platforms. One of the key features of SwiftUI is the ability to use view modifiers to modify the appearance and behavior of views.

View modifiers are methods that are applied to a view to change its properties. They are very similar to the way CSS styles are applied to HTML elements. The main difference is that view modifiers in SwiftUI are applied to a view's properties directly, rather than through a separate stylesheet.

Built-in View Modifiers

One of the most commonly used built-in view modifiers is the .frame() modifier, which is used to change the size and position of a view. For example, if you have a button that you want to make larger, you can use the .frame() modifier to change its width and height.

Another commonly used view modifier is the .background() modifier, which is used to change the background color of a view. For example, if you have a text field that you want to make red, you can use the .background() modifier to change its background color to red.

TextField("Enter your name", text: $name)
    .background(Color.red)

You can also use a .background() modifier to apply gradient background.

Text("Hello World")
    .background(LinearGradient(gradient: Gradient(colors: [.white, .black]), startPoint: .top, endPoint: .bottom))

You can also use this modifier multiple times to apply multiple background colors to a single view. The last applied modifier will be visible.

Text("Hello World")
    .background(Color.red)
    .background(Color.yellow)

In this example, the text will have a yellow background color, because it was the last one applied.

Custom View Modifiers

In addition to these built-in view modifiers, you can also create your own custom view modifiers. These can be used to encapsulate a set of properties and apply them to multiple views. For example, you can create a view modifier that applies a rounded corner and a shadow to a view.

To create a custom view modifier, you can define a struct that conforms to the ViewModifier protocol and implement the body property.

struct RoundedCorners: ViewModifier {
    func body(content: Content) -> some View {
        content
            .clipShape(RoundedRectangle(cornerRadius: 20))
            .shadow(radius: 5)
    }
}

You can then use this custom view modifier by calling the .modifier() method on a view.

Text("Hello World")
    .modifier(RoundedCorners())

Here is another example to utilise custom view modifier.

struct Padding: ViewModifier {
    let padding: CGFloat

    func body(content: Content) -> some View {
        content
            .padding(padding)
    }
}

You can also chain multiple custom view modifiers together. For example, you can add a rounded corner and padding to a view like this:

Text("Hello World")
    .modifier(RoundedCorners())
    .modifier(Padding(padding: 20))

Custom view modifiers can also take parameters like the above example. You can also pass a binding variable as a parameter to a custom view modifier, this way you can change the value of the parameter in real time

struct Padding: ViewModifier {
    @Binding var padding: CGFloat

    func body(content: Content) -> some View {
        content
            .padding(padding)
    }
}

struct ContentView: View {
    @State var padding: CGFloat = 20
    var body: some View {
        VStack {
            Text("Hello World")
                .modifier(Padding(padding: $padding))
            Slider(value: $padding, in: 0...50)
        }
    }
}

In this example, the Text will have 20 points of padding, but you can change it in real time by moving the slider.

As you can see, custom view modifiers are a great way to encapsulate common functionality and apply it to multiple views in a consistent and reusable way. They are also powerful tools for creating dynamic and responsive user interfaces.

Conclusion

In conclusion, view modifiers are a powerful feature of SwiftUI that allow you to easily change the appearance and behavior of views. They are similar to CSS styles in HTML, but are applied directly to a view's properties. You can also create your own custom view modifiers to encapsulate a set of properties and apply them to multiple views.

This blog powered by ChatGPT https://chat.openai.com/chat

If you read this article you may know about https://newrelic.com.
It's powerful tool to monitor your system performance, from Frontend to Backend or database.

To prepare for new version release, we need to monitor status of our latest app to find issues that can not detected in testing phase, and can react to incident faster.

Below are some queries that i'm using...

1. App Launches - how many device launched your current version

FROM MobileSession SELECT uniqueCount(deviceUuid) FACET appVersion WHERE appVersion = '9.9.9' AND appName = 'sample-ios-app' TIMESERIES AUTO SINCE '2022-08-31 00:00:00'

2. Upgraded From - which app version is upgraded to your newest version

FROM MobileSession SELECT count(upgradeFrom) WHERE appVersion = '9.9.9' AND appName = 'sample-ios-app' FACET upgradeFrom TIMESERIES AUTO SINCE last week

3. Crash Count and crash ratio

FROM MobileCrash SELECT count(*)  AS 'Crash Count' WHERE appVersion = '9.9.9' AND appName = 'sample-ios-app' TIMESERIES AUTO SINCE 1 day ago

FROM MobileSession, MobileCrash SELECT percentage(uniqueCount(sessionId), WHERE category = 'Crash') AS `Crash Rate` WHERE appVersion = '9.9.9' AND appName = 'sample-ios-app' TIMESERIES AUTO SINCE 1 day ago

4. Crashes by all Versions

FROM MobileCrash SELECT count(*) WHERE appName = 'sample-ios-app' WHERE crashFingerprint NOT IN () FACET `appVersion` TIMESERIES SINCE '2022-08-31 00:00:00'

FROM MobileSession, MobileCrash SELECT percentage(uniqueCount(sessionId), WHERE category = 'Crash')  WHERE appName = 'sample-ios-app' FACET `appVersion` TIMESERIES SINCE '2022-08-31 00:00:00'

5. App Launches - all versions

FROM MobileSession SELECT uniqueCount(deviceUuid) FACET appVersion WHERE appVersion not like '%dirty' AND appName = 'sample-ios-app' TIMESERIES AUTO SINCE this week

6. UUID by App Versions

FROM Mobile SELECT abs(uniqueCount(deviceUuid)) WHERE appName like 'sample-ios-app' FACET appVersion SINCE this month

Hope those queries can help.

After making builds with Fastlane and exported a valid .ipa, you need to automate the process of uploading the file to Testflight. You can do it in two ways with upload_to_testflight (or pilot) action.

With AppStore Connect API key

https://docs.fastlane.tools/app-store-connect-api/#using-fastlane-api-key-json-file

The upload_to_testflight action need an App store connect api key to work. It's result of this action app_store_connect_api_key, the action for creating a JWT from a .p8 file.

lane :release do
  api_key = app_store_connect_api_key(
    key_id: "Q58Q4Y9A5W",
    issuer_id: "69a6de95-7865-47e3-e053-5b8c7c11a4d1",
    key_filepath: "./AuthKey_Q58Q4Y9A5W.p8",
    duration: 1200, # optional (maximum 1200)
    in_house: false # optional but may be required if using match/sigh
  )

  upload_to_testflight(
    api_key: api_key,
    skip_submission: true,
    ipa: "#{ipa_path}",
    skip_waiting_for_build_processing: true,
  )
end

.p8 file, key_id, issuer_id are all easily get from App Store Connect webpage.

Login to your developer account, go to Users and Access, then find Request Access button in Keys tab.

After requesting access, you can Generate any Key for some roles, use Issue ID, KeyID and Download API key (as an .p8 file) for app_store_connect_api_key lane above.

There's another way to specific .p8 key for app_store_connect_api_key lane. It's using key_content instead of key_filepath. In that case, you need to modify the .p8's content by replacing all new lines with \n, to make it in one line.

For example:
Default content from App Store Connect:

-----BEGIN PRIVATE KEY-----
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
EEEEEEEEEEEEE
-----END PRIVATE KEY-----

change to:

-----BEGIN PRIVATE KEY-----\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB\nCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC\nDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD\nEEEEEEEEEEEEE\n-----END PRIVATE KEY-----

Find more detail about the key here
https://docs.fastlane.tools/actions/app_store_connect_api_key/

With Enviroment variables FASTLANE_USER and FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD

The second way to upload to App Store is to use lane upload_to_testflight. With this lane, you need to prepare two environment variables as Credentials for uploading.

About environment variables: https://support.apple.com/guide/terminal/use-environment-variables-apd382cc5fa-4f58-4449-b20a-41c53c006f8f/mac

Let take a look at an example:

lane :release do
  upload_to_testflight(
    apple_id: "your-app-apple-id"
    skip_submission: true,
    ipa: "#{ipa_path}",
    skip_waiting_for_build_processing: true,
  )
end

It's simpler than the first lane, but there's no any user credentials in lane parameters, like .p8 key, so to let the script work, we need to find out 2 environment variables: FASTLANE_USER &FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD and set it before running the script.

• FASTANE_USER is your developer id
• FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD is one of App-Specific Passwords in your apple id managemeng page https://appleid.apple.com/account/manage

Details can be found: https://docs.fastlane.tools/best-practices/continuous-integration/#application-specific-passwords

• apple_id can be found in your app's information page in App Store Connect web page.

Let's try to see result. If you found any problem please let me know in comment section down below.

Conclusion

The first way seems more complicated than the second way, and you need to be an admin to generate .p8 key. But you can control the flow by put the key in any place you want to automate and you don't rely on any user's account.

The second way is base on account, and if you work in an organization the account can be expired if people leave. So it's suitable for personal account.

Thanks a lot for reading. Happy coding.

Overview

Bloom filter is Probabilistic data struct, it can tell an object is definitely not exist in the set or problably exist in the set.
Means when it tells false, it is the 100% correct, and when it tells true it's not 100%, there's a chance that element doesn't exist in the set.

It's just a filter, and doesn't store actual objects.
So for sets of large number of elements, there's huge performance different between a hash table and a Bloom filter.

The following figure describes how to add an element.

A Bloom Filter contains set of Hash functions and a bit array to store results.

• When inserting an element, we compute all hashes and turn on the certain bit.
• When checking existence of an element, we also compute all hashes by hash functions above. Hash results will be used to pick the status of bits.
  If any bit is not turned on, the element does not exist.
  If all bits are turned on, we can tell the element might exist.

It's easily to figure that bloom filter cannot support deletetion, if we turn off any bit it may affects existence of many elements.

Implementation

Here is simple implementation. We support three methods for our Bloom Filter: insert, filter, and isEmpty

class BloomFilter<T> {
  private var array: [Bool]
  private var hashes: [(T) -> Int]

  init(size: Int = 1024, hashes: [(T) -> Int]) {
    self.array = [Bool](repeating: false, count: size)
    self.hashes = hashes
  }

  private func computeHashes(_ value: T) -> [Int] {
    return hashes.map { hash in abs(hash(value) % array.count) }
  }
}

extension BloomFilter {
  func insert(_ element: T) {
    for hashValue in computeHashes(element) {
      array[hashValue] = true
    }
  }

  func filter(_ value: T) -> Bool {
    return computeHashes(value)
        .map { hashValue in array[hashValue] }
        .reduce(true, { $0 && $1 })
  }

  func isEmpty() -> Bool {
    return array.reduce(true) { prev, next in prev && !next }
  }
}

Hash functions

There's a swift evolution about hash functions.
https://github.com/apple/swift-evolution/blob/master/proposals/0206-hashable-enhancements.md
Hashable protocol was changed from property hashValue:Int to additional hashInto(hasher: Hasher) function

Swift 1.0

struct GridPoint {
  var x: Int
  var y: Int
}

extension GridPoint: Hashable {
  var hashValue: Int {
    return x.hashValue ^ y.hashValue &* 16777619
  }

  static func == (lhs: GridPoint, rhs: GridPoint) -> Bool {
    return lhs.x == rhs.x && lhs.y == rhs.y
  }
}

Swift 4.1~

extension GridPoint: Hashable {
  func hash(into hasher: inout Hasher) {
    hasher.combine(x)
    hasher.combine(y)
  }
}

We can take advantage of this Hasher to implement Hash functions for our Bloom filter by providing a feed value for each hash. Under the hood of Hasher is SipHash.

func hash(_ valueToHash: T) -> Int where T is Hashable {
  var hasher = Hasher()
  hasher.combine(nthFunctionFeedValue)
  hasher.combine(valueToHash)
  return hasher.finalize()
}

There's also other hash function like naive or djb2

func naiveHash(_ string: String) -> Int {
  let unicodeScalars = string.unicodeScalars.map { Int($0.value) }
  return unicodeScalars.reduce(0, +)
}

func djb2Hash(_ string: String) -> Int {
  let unicodeScalars = string.unicodeScalars.map { $0.value }
  return unicodeScalars.reduce(5381) {
    ($0 << 5) &+ $0 &+ Int($1)
  }
}

TLV is basically a multi-levels data format represented by an array of bytes. There're no wasted data like JSON with brackets or spaces, or XML with duplicated tag names.

The data includes 3 parts Tag, Length of Value, and Value.

Read this Article first

Tag - type of TLV

Depend on system or device, there's a pre-defined Tags list.
EMV smartcards also provide common Tags list, these tags should also be considering.

https://emvlab.org/emvtags/all/

Tag's data type is unsign integer 32bit UInt32, it follows ISO/IEC 8825 for BerTLV.

If all bits from 0 → 5 of first byte is set, we use it with all next bytes that have 7th bit is set.

Here is pseudo code:

private func getTag(_ stream: InputStream) -> TLV.Tag? {
   guard let first = stream.readByte() else { return nil }
   
   /// check 5 bits of first byte is set
   guard first & 0x1f == 0x1f else { /// = 0001 1111 = 31
       return TLV.Tag(rawValue: UInt32(first))
   }
  
   var result: [UInt8] = []
   /// read until finding a byte that has 7th bit not set
   while let next = stream.readByte() {
       result.append(next)
       if next & 0x80 != 0x80 { /// = 1000 0000 = 128
           break
       }
   }
   result.insert(first, at: 0)
   return TLV.Tag(rawValue: UInt32(result))
}

extension TLV {
    enum Tag: UInt32, CaseIterable {
        case responseData = 0xe1
        case cardStatus = 0x48
        case applicationLabel = 0x50
        ....
    }
}

Length - length of Value

Because length of Value is dynamic so we need to know how many bytes we should read.

Next TLV starts at the end of current TLV's Value.
For Miura Card Readers the Length is read as following cases of first byte:

If the 8th bit of first byte is not set, use it as Length
If the 8th bit of first byte is set, unset it and use new value as length of Length

func getLength(on stream: InputStream) -> TLV.Length {
    let firstByte = stream.readByte()
    guard firstByte & 0x80 == 0x80 else {
        return TLV.Length(firstByte)
    }
    let lenOfLength = max(Int(first & 0x7f), 1)
    let lengthBytes = stream.readBytes(count: lenOfLength)
    return TLV.Length(lengthBytes)
}

extension TLV {
    typealias Length = UInt32
}

public extension UnsignedInteger {
    init(_ bytes: [UInt8]) {
        precondition(bytes.count <= MemoryLayout<Self>.size)
        var value: UInt64 = 0
        for byte in bytes {
            value <<= 8
            value |= UInt64(byte)
        }
        self.init(value)
    }
}

Value

Value has variety types: String, a sub TLV or list of TLVs.
Because Value can contains sub TLVs, so we can consider TLV is Tree or Graph data structure. Some traversal algorithim like Pre-Order, In-Order, Level Order should be implemented to search sub tags.

The properly way to parse TLV is using Recursive or Queue:

let parser = TLVParser()

extension TLV {
	struct Value {
		let tlvs: OrderedSet<TLV>?
		let string: String?

		init(bytes: [UInt8]) {
			let data = Data(bytes)
			let tlvs = parser.parse(data)
			if !tlvs.isEmpty { self.tlvs = tlvs }
			else { self.string = String(data: data, encoding: .utf8) }
		}
	}
}
struct TLVParser {
	func parse(data: Data) -> OrderedSet<TLV> {
        let stream = InputStream(data: data)
    	stream.open()
    	defer { stream.close() }

		var tlvs = OrderedSet<TLV>()
    	while dataStream.hasBytesAvailable {
	 		guard let tag = getTag(on: stream) else { return tlvs }
			let length = getLength(on stream: stream)
    		let value = Value(stream.readBytes(count: length))
			tlvs.append(TLV(tag, length, value))
    	}
        return tlvs
	} 
}

The result TLVs should be in-order and can be searched using its keys.
In summary, TLV is lightweight but not application developer friendly.
Apple also provide the CryptoTokenKit with TLV, BerTLV parser. But seems not work well with Miura devices because of private Tags.
https://developer.apple.com/documentation/cryptotokenkit/tktlvrecord

Happy Coding.

self.lblTitle = "Untitled".localized

Things getting easier with SwiftUI. There's new struct was introduced, LocalizedStringKey. We just need to assign correct key to correct label, the rest is on the framework.

Let take a quicklook at official document.

https://developer.apple.com/documentation/swiftui/localizedstringkey

They say, when we use the initializer with a string like Text("Hello World"), SwiftUI will convert to a LocalizedStringKey and uses that to lookup the a localization of the Hello World string.

There're some elements that use string as param for initializer

Text("Username")

Button("Sign In", action: signIn)

Label("Lightning", systemImage: "bolt.fill")

Link("View Our Terms of Service",
      destination: URL(string: "https://www.example.com/TOS.html")!)

Picker("Flavor", selection: $selectedFlavor) {
    Text("Chocolate").tag(Flavor.chocolate)
    Text("Vanilla").tag(Flavor.vanilla)
    Text("Strawberry").tag(Flavor.strawberry)
}

Toggle("Vibrate on Ring", isOn: $vibrateOnRing)

They are called stringLiteral. But how about using variable instead of fixed string?

var signTitle = "Sign In"
Button(signTitle, action: signIn)

This should not work automatically to prevent unexpected values. To use localized string instead of variable's raw data, we just need to convert it to localized key manually.

var signTitle = "Sign In"
Button(LocalizedStringKey(signTitle), action: signIn)

Last but not least, it takes less effort than to UIKit to change language while app is running. A simple line of code to switch Locale, all LocalizedStringKeys, include all child-views, will be reloaded automatically.

ContentView()
    .environment(\.locale, .init(identifier: "ja"))

Hope this tips will help you enjoy SwiftUI more.

Introduction

At the moment of writting this post, Bitcoin just hit $60,000 with a market cap over 1 TRILLION USD. That's huge number.

If you invested 250$ for 17 Bitcoin in 2013, now you are billionaire.
I wish I have a time-machine to travel to the past and buy some :cry:

Hmm just get back to life :). As you may know, every Bitcoin transactions block need to be sealed, when someone seal it correctly they will get rewards. So how to generate the Stamp to seal?

Each block of transactions contains header and body. Body is the list of transactions, header is a string which has format:
version:hashPrevblock:hashMerkleRoot:time:bits:nonce

• version: block version number
• hashPrevBlock: 256-bit hash of the previous block header
• hashMerkleRoot: 256-bit hash of current block body
• time: current block time stamp, since 1970-01-01T00:00 UTC
• bits: current target in compact format
• nonce: 32bit-number start from 0

A block is considered as valid one, if SHA256(SHA256(header)) passing the verification algorithm - check result string has exact number of leading zeros. Valid header is the Stamp to be mined.

The algorithm to calculate header based on Hashcash algorithm.
Let see how it works.

The Input and the Output

Input

version: version of block
resource: consider as block information (hashPrevBlock and hashMerkleRoot)
bits: leading zeros padding to validate (default is 20)
ext: additional information (optional)
timestamp: current datetime in format yyyyMMddHHmmss
saltLength: length to create a random string to make result unique (default is 16)

the final input:
version:bits:timestamp:resource:ext:saltString

Output

Output format should be: version:bits:timestamp:resource:ext:saltString:counter

counter was made while algorithm running.
It starts from 0 until valid output was found.

Algorithm

The algorithm is not hard as you though:

• Build input strings with correct format
• Add counter to input
• Hash the input
• Repeat step 2 and 3 if hashed value is not contains exactly leading zeros
• Return result if the loop was breaked.

func mint(
    version: Int,
    resource: String,
    bits: Int = 20,
    ext: String = "",
    timestamp: String,
    saltLength: Int = 16
) -> String {
    let salt = String.salt(length: saltLength)
    let input = "\(version):\(bits):\(timestamp):\(resource):\(ext):\(salt)"
    
    var counter = 0
    while(true) {
        let challenge = input + ":\(String(format: "%02x", counter))"
        let hashed = challenge.sha256()
        if hashed.hasLeadingZeros(bits) {
            return challenge
        }
        counter += 1
    }
}

extension String {
    static func salt(length: Int) -> String {
        let chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ+/="
        return (0..<length).map { _ -> String in
            let random = Int.random(in: 0..<chars.count)
            let index = chars.index(chars.startIndex, offsetBy: random)
            return String(chars[index])
        }.joined()
    }
    
    func sha256() -> String {
        let data = self.data(using: .utf8)!
        let hashed = SHA256.hash(data: data)
        return hashed.compactMap { String(format: "%02x", $0) }
            .joined()
    }
    
    func hasLeadingZeros(_ zerosCount: Int) -> Bool {
        let digits = Int(ceil(Double(zerosCount) / 4))
        let zeros = String(repeating: "0", count: digits)
        let indexToCheck = self.index(self.startIndex, offsetBy: digits)
        return zeros == self[startIndex..<indexToCheck]
    }
}

extension Date {
    func timestamp() -> String {
        let formatter = DateFormatter()
        formatter.dateFormat = "yyyyMMddHHmmss"
        return formatter.string(from: self)
    }
}

Verify the seal

To verify this seal version:bits:timestamp:resource:ext:saltString:counter
we need to do some steps:

• verify order of elements
• check expirations of timestamp
• verify resource is matching
• verify hashed string contains correct leading zeros.

protocol Validator {
    var version: Int { get }
    var timeFormat: String { get }
    var expiration: UInt? { get }
    var bits: UInt { get }
    
    func validate(_ stamp: String, _ resource: String?) -> Bool
}

extension Validator {
    func validate(_ stamp: String, _ resource: String?) -> Bool {
        let components = stamp.components(separatedBy: ":")
        
        guard components.count > 6 else {
            return false
        }
        
        guard checkVersion(components[0]),
              checkBits(components[1]),
              checkDate(components[2]),
              checkResource(components[3], with: resource) else {
            return false
        }
        
        return checkHash(stamp)
    }
    
    private func checkDate(_ date: String) -> Bool {
        let dateformatter = DateFormatter()
        dateformatter.dateFormat = self.timeFormat
        guard let date = dateformatter.date(from: date) else {
            return false
        }
        
        if let expiration = self.expiration {
            let expDate = Date(timeIntervalSinceNow: -TimeInterval(expiration))
            guard (date >= expDate) else {
                return false
            }
        }
        
        return true
    }
    
    private func checkVersion(_ ver: String) -> Bool {
        return (Int(ver) ?? 1) <= self.version
    }
    
    private func checkResource(_ res: String, with res2: String?) -> Bool {
        if res2 == nil {
            return true
        }
        return res2 == res
    }
    
    private func checkBits(_ bits: String) -> Bool {
        return Int(bits) == Int(self.bits)
    }
    
    private func checkHash(_ string: String) -> Bool {
        return string.sha256().hasLeadingZeros(bits)
    }
}

let give it a try

let stamp = mint(version: 1, resource: "hallo", timestamp: Date().timestamp())
print(stamp)
print(Ver1Validator().validate(stamp, "hallo"))

this is a sample valid result i tried on my machine:

1:20:20210403170942:hallo::MoxqvFOLGnwjs=Ko:8717
with hashed value
000005219105fb754ab98d4715e23fd2b489823b0468c337db7121c6432bbe9e

Conclusion

Finally we did it... That's good start to deep understand how crypto currency works.

But this algorithm is just a tiny part of crypto currency.
There're much more difficulty in real world like: tool to create transactions, to to distribute the whole block-chain to validators (miner) or infrastructure for system...

Let see more in near future.