by Joche Ojeda | Jun 10, 2024 | Blockchain, C#, Smart contracts, Stratis
Introduction
Blockchain technology has revolutionized various industries by providing a decentralized and secure way to manage data and transactions. At the heart of this innovation are smart contracts—self-executing contracts with the terms directly written into code. My journey into blockchain development began with the excitement of these possibilities, but it also came with challenges, particularly with the Solidity programming language. However, everything changed when I discovered the Stratis platform, which supports smart contracts using C#, making development much more accessible for me. In this article, I’ll share my experiences, challenges, and the eventual breakthrough that came with Stratis.
Challenges with Solidity
Solidity is the most popular language for writing smart contracts on Ethereum, but it has a steep learning curve. My background in programming didn’t include a lot of JavaScript-like languages, so adapting to Solidity’s syntax and concepts was daunting. The process of writing, testing, and deploying smart contracts often felt cumbersome. Debugging was a particular pain point, with cryptic error messages and a lack of mature tooling compared to more established programming environments.
The complexity and frustration of dealing with these issues made me seek an alternative that could leverage my existing programming skills. I wanted a platform that was easier to work with and more aligned with languages I was already comfortable with. This search led me to discover Stratis.
Introduction to Stratis
Stratis is a blockchain development platform designed to meet the needs of enterprises and developers by offering a simpler and more efficient way to build blockchain solutions. What caught my attention was its support for C#—a language I was already proficient in. Stratis allows developers to create smart contracts using C#, integrating seamlessly with the .NET ecosystem.
This discovery was a game-changer for me. The prospect of using a familiar language in a robust development environment like Visual Studio, combined with the powerful features of Stratis, promised a much smoother and more productive development experience.
Why Stratis Stood Out
The primary benefit of using C# over Solidity is the familiarity and maturity of the development tools. With C#, I could leverage the rich ecosystem of libraries, tools, and frameworks available in the .NET environment. This not only sped up the development process but also reduced the time spent on debugging and testing.
Stratis offers a comprehensive suite of tools designed to simplify blockchain development. The Stratis Full Node, for instance, provides a fully functional blockchain node that can be easily integrated into existing applications. Additionally, Stratis offers a smart contract template for Visual Studio, making it straightforward to start building and deploying smart contracts.
Another significant advantage is the support and community around Stratis. The documentation is thorough, and the community is active, providing a wealth of resources and assistance for developers at all levels.
Conclusion
Transitioning from Solidity to Stratis was a pivotal moment in my blockchain development journey. The challenges I faced with Solidity were mitigated by the ease and familiarity of C#. Stratis provided a robust and efficient platform that significantly improved my development workflow.
In the next article, I will dive into the practical steps of setting up the Stratis development environment. We’ll cover everything you need to get started, from installing the necessary tools to configuring your first Stratis Full Node. Stay tuned for a detailed guide that will set the foundation for your journey into C# smart contract development.
by Joche Ojeda | Jun 5, 2024 | C#, Data Synchronization
Introduction
In modern API development, choosing the correct return type is crucial for performance, flexibility, and maintainability. In my SyncFramework server API, I opted to use strings as the return type. This decision stems from the need to serialize messages efficiently and flexibly, ensuring seamless communication between the server and client. This article explores the rationale behind this choice, specifically focusing on C# code with HttpClient and Web API on the server side.
The Problem
When building APIs, data serialization and deserialization are fundamental operations. Typically, APIs return objects that are automatically serialized into JSON or XML. While this approach is straightforward, it can introduce several challenges:
- Performance Overhead: Automatic serialization/deserialization can add unnecessary overhead, especially for large or complex data structures.
- Lack of Flexibility: Relying on default serialization mechanisms can limit control over the serialization process, making it difficult to customize data formats or handle specific serialization requirements.
- Interoperability Issues: Different clients may require different data formats. Sticking to a single format can lead to compatibility issues.
The Solution: Using Strings
To address these challenges, I decided to use strings as the return type for my API. Here’s why:
- Control Over Serialization: By returning a string, I can serialize the data myself, ensuring that the format meets specific requirements. This control is essential for optimizing the data format and ensuring compatibility with various clients.
- Performance Optimization: Custom serialization allows me to optimize the data structure, potentially reducing the size of the serialized data and improving transmission efficiency. For example, converting a complex object to a compressed byte array and then encoding it as a string can save bandwidth.
- Flexibility: Using strings enables me to easily switch between different serialization formats (e.g., JSON, XML, binary) based on the client’s needs without changing the API contract. This flexibility is crucial for maintaining backward compatibility and supporting multiple client types.
Implementation in C#
Here’s a practical example of how this approach is implemented using C#:
Server Side: Web API
using System;
using System.Text;
using System.Web.Http;
public class MyApiController : ApiController
{
[HttpGet]
[Route("api/getdata")]
public IHttpActionResult GetData()
{
var data = new MyData
{
Id = 1,
Name = "Sample Data"
};
// Custom serialization to JSON string
var serializedData = SerializeData(data);
return Ok(serializedData);
}
private string SerializeData(MyData data)
{
// Use custom serialization logic (e.g., JSON, XML, or binary)
return Newtonsoft.Json.JsonConvert.SerializeObject(data);
}
}
public class MyData
{
public int Id { get; set; }
public string Name { get; set; }
}
Client Side: HttpClient
using System;
using System.Net.Http;
using System.Threading.Tasks;
public class ApiClient
{
private readonly HttpClient _httpClient;
public ApiClient()
{
_httpClient = new HttpClient();
}
public async Task GetDataAsync()
{
var response = await _httpClient.GetStringAsync("http://localhost/api/getdata");
// Custom deserialization from JSON string
return DeserializeData(response);
}
private MyData DeserializeData(string serializedData)
{
// Use custom deserialization logic (e.g., JSON, XML, or binary)
return Newtonsoft.Json.JsonConvert.DeserializeObject(serializedData);
}
}
public class MyData
{
public int Id { get; set; }
public string Name { get; set; }
}
Benefits Realized
By using strings as the return type, the SynFramework server API achieves several benefits:
- Enhanced Performance: Custom serialization reduces the payload size and improves response times.
- Greater Flexibility: The ability to easily switch serialization formats ensures compatibility with various clients.
- Better Control: Custom serialization allows fine-tuning of the data format, improving both performance and interoperability.
Conclusion
Choosing strings as the return type for the SyncFramework server API offers significant advantages in terms of performance, flexibility, and control over the serialization process. This approach simplifies the management of data formats, ensures efficient data transmission, and enhances compatibility with diverse clients. For developers working with C# and Web API, this strategy provides a robust solution for handling API responses effectively.
by Joche Ojeda | Jun 4, 2024 | Data Synchronization
In the world of software development, exception handling is a critical aspect that can significantly impact the user experience and the robustness of the application. When it comes to client-server architectures, such as the SyncFramework, the way exceptions are handled can make a big difference. This blog post will explore two common patterns for handling exceptions in a C# client-server API and provide recommendations on how clients should handle exceptions.
Throwing Exceptions in the API
The first pattern involves throwing exceptions directly in the API. When an error occurs in the API, an exception is thrown. This approach provides detailed information about what went wrong, which can be incredibly useful for debugging. However, it also means that the client needs to be prepared to catch and handle these exceptions.
public void SomeApiMethod()
{
// Some code...
if (someErrorCondition)
{
throw new SomeException("Something went wrong");
}
// More code...
}
Returning HTTP Error Codes
The second pattern involves returning HTTP status codes to indicate the result of the operation. For example, a `200` status code means the operation was successful, a `400` series status code means there was a client error, and a `500` series status code means there was a server error. This approach provides a standard way for the client to check the result of the operation without having to catch exceptions. However, it may not provide as much detailed information about what went wrong.
[HttpGet]
public IActionResult Get()
{
try
{
// Code that could throw an exception
}
catch (SomeException ex)
{
return StatusCode(500, $"Internal server error: {ex}");
}
}
Best Practices
In general, a good practice is to handle exceptions on the server side and return appropriate HTTP status codes and error messages in the response. This way, the client only needs to interpret the HTTP status code and the error message, if any, and doesn’t need to know how to handle specific exceptions that are thrown by the server. This makes the client code simpler and less coupled to the server.
Remember, it’s important to avoid exposing sensitive information in error messages. The error messages should be helpful for the client to understand what went wrong, but they shouldn’t reveal any sensitive information or details about the internal workings of the server.
Conclusion
Exception handling is a crucial aspect of any application, and it’s especially important in a client-server architecture like the SyncFramework. By handling exceptions on the server side and returning meaningful HTTP status codes and error messages, you can create a robust and user-friendly application. Happy coding!
by Joche Ojeda | Apr 24, 2024 | C#, netframework
A Beginner’s Guide to System.Security.SecurityRules and SecuritySafeCritical in C#
Introduction
In the .NET Framework, security is a critical concern. Two attributes, System.Security.SecurityRules and SecuritySafeCritical, play a significant role in enforcing Code Access Security (CAS).
System.Security.SecurityRules
The System.Security.SecurityRules attribute specifies the set of security rules that the common language runtime should enforce for an assembly. It has two levels: Level1 and Level2.
Level1
Level1 uses the .NET Framework version 2.0 transparency rules. Here are the key rules for Level1:
- Public security-critical types and members are treated as security-safe-critical outside the assembly.
- Security-critical types and members must perform a link demand for full trust to enforce security-critical behavior when they are accessed by external callers.
- Level1 rules should be used only for compatibility, such as for .NET Framework 2.0 assemblies.
[assembly: System.Security.SecurityRules(System.Security.SecurityRuleSet.Level1)]
public class MyClass
{
// Your code here
}
SecuritySafeCritical
The SecuritySafeCritical attribute identifies types or members as security-critical and safely accessible by transparent code. Code marked with SecuritySafeCritical must undergo a rigorous security audit to ensure that it can be used safely in a secure execution environment. It must validate the permissions of callers to determine whether they have authority to access protected resources used by the code.
[System.Security.SecuritySafeCritical]
public void MyMethod()
{
// Your code here
}
Relationship between System.Security.SecurityRules and SecuritySafeCritical
The System.Security.SecurityRules and SecuritySafeCritical attributes work together to enforce security in .NET Framework. An assembly marked with SecurityRules(SecurityRuleSet.Level1) uses the .NET Framework version 2.0 transparency rules, where public security-critical types and members are treated as security-safe-critical outside the assembly.
The concept of trusted Code
Trusted code refers to code that has been granted certain permissions and is considered safe to execute. It’s a combination of techniques, policies, and procedures for which there is no plausible scenario in which a document retrieved from or reproduced by the system could differ substantially from the document that is originally stored. In other words, trusted code certifies that electronically stored information (ESI) is an authentic copy of the original document or information.
Use Cases and Examples
Consider a scenario where you have a method that performs a critical operation, such as accessing a protected resource. You want to ensure that this method can only be called by trusted code. You can mark this method as SecuritySafeCritical to enforce this.
[System.Security.SecuritySafeCritical]
public void AccessProtectedResource()
{
// Code to access protected resource
}
In this case, the AccessProtectedResource method can only be called by code that has been granted the necessary permissions. This helps to prevent unauthorized access to the protected resource.
Conclusion
Understanding the System.Security.SecurityRules and SecuritySafeCritical attributes is crucial when developing secure .NET applications. By using these attributes correctly, you can enforce robust security rules and protect your application from potential threats. Always remember, with great power comes great responsibility!
I hope this article helps you understand these concepts better. Happy coding! 😊
by Joche Ojeda | Jan 2, 2024 | A.I
This article demonstrates the process of creating, training, saving, and loading a spam detection AI model using ML.NET, but also emphasizes the reusability of the trained model. By following the steps in the article, you will be able to create a model that can be easily reused and integrated into your .NET applications, allowing you to effectively identify and filter out spam emails.
Prerequisites
- Basic understanding of C#
- Familiarity with ML.NET and machine learning concepts
Code Overview
-
- Import necessary namespaces:
using System;
using System.IO;
using System.Linq;
using Microsoft.ML;
using Microsoft.ML.Data;
-
- Define the
Email
class and its properties:
public class Email
{
public string Content { get; set; }
public bool IsSpam { get; set; }
}
-
- Create a sample dataset for training the model:
var sampleData = new List<Email>
{
new Email { Content = "Buy cheap products now", IsSpam = true },
new Email { Content = "Meeting at 3 PM", IsSpam = false },
};
-
- Initialize a new MLContext, which is the main entry point to ML.NET:
var mlContext = new MLContext();
-
- Load the sample data into an IDataView:
var trainData = mlContext.Data.LoadFromEnumerable(sampleData);
-
- Define the data processing pipeline and the training algorithm (SdcaLogisticRegression):
var pipeline = mlContext.Transforms.Text.FeaturizeText("Features", nameof(Email.Content))
.Append(mlContext.BinaryClassification.Trainers.SdcaLogisticRegression());
-
- Train the model:
var model = pipeline.Fit(trainData);
-
- Save the trained model as a .NET binary:
mlContext.Model.Save(model, trainData.Schema, "model.zip");
-
- Load the saved model:
var newMlContext = new MLContext();
DataViewSchema modelSchema;
ITransformer trainedModel = newMlContext.Model.Load("model.zip", out modelSchema);
-
- Create a prediction engine:
var predictionEngine = mlContext.Model.CreatePredictionEngine<Email, SpamPrediction>(trainedModel);
-
- Test the model with a sample email:
var sampleEmail = new Email { Content = "Special discount, buy now!" };
var prediction = predictionEngine.Predict(sampleEmail);
-
- Output the prediction:
Debug.WriteLine($"Email: '{sampleEmail.Content}' is {(prediction.IsSpam ? "spam" : "not spam")}");
-
- Assert that the prediction is correct:
Assert.IsTrue(prediction.IsSpam);
-
- Verify that the model was saved:
if(File.Exists("model.zip"))
Assert.Pass();
else
Assert.Fail();
Conclusion
In this article, we explained a simple spam detection model in ML.NET and demonstrated how to train and test the model. This code can be extended to build more complex models, and can be used as a starting point for exploring machine learning in .NET.
Github Repo