Today we will try a programming assistant DevChat to see if it can improve our daily programming efficiency. As a programming assistant, let’s take a look at some of its differences and features with products in the same field as Copilot and CodeWhisperer. Set a small goal, implement a simple RBAC model through DevChat, and give it a try to see if the whole process is smooth enough.
First of all, let me talk about the installation process. It is quite convenient. In the form of VsCode plug-in, it is convenient for developers to seamlessly connect directly during the development process. There is no need to download the software separately. You can chat while developing. After chatting with it, the development task is completed. Okay, the whole idea is pretty good. The plug-in only needs to fill in the corresponding Key to take effect. Compared with several other products, it has certain convenience advantages and does not require additional login accounts.
Next, let’s start our programming. Let’s use the Go language to implement a RBAC permission model.
/code Can you implement the RBAC model by Golang?
package main
import "fmt"
// Define roles
const (
RoleGuest = "guest"
RoleUser = "user"
RoleAdmin = "admin"
)
//User struct to hold user information
typeUser struct {
Name string
Role string
}
// Permissions struct to define allowed actions for a role
typePermissions struct {
CanView bool
CanEdit bool
CanDelete bool
}
// RolePermissionsMap maps roles to their respective permissions
var RolePermissionsMap = map[string]Permissions{
RoleGuest: {
CanView: true,
CanEdit: false,
CanDelete: false,
},
RoleUser: {
CanView: true,
CanEdit: true,
CanDelete: false,
},
RoleAdmin: {
CanView: true,
CanEdit: true,
CanDelete: true,
},
}
// CheckPermission checks if a user has permission for a specific action
func CheckPermission(user User, action string) bool {
permissions := RolePermissionsMap[user.Role]
switch action {
case "view":
return permissions.CanView
case "edit":
return permissions.CanEdit
case "delete":
return permissions.CanDelete
default:
return false
}
}
func main() {
//Create some users
user1 := User{"John", RoleGuest}
user2 := User{"Alice", RoleUser}
user3 := User{"Admin", RoleAdmin}
//Example usage
fmt.Println(user1.Name, "can view:", CheckPermission(user1, "view")) // Output: true
fmt.Println(user2.Name, "can delete:", CheckPermission(user2, "delete")) // Output: false
fmt.Println(user3.Name, "can edit:", CheckPermission(user3, "edit")) // Output: true
}
Here we can see that the given Demo basically meets the requirements, implements a simple RBAC model, and generates certain examples for us.
Next, we need to make certain business adjustments to test it. Now if a new requirement comes, add a super administrator. If it is a super administrator, it will have all permissions and see if it can be successfully implemented.
/code Based on the above code, implement a super administrator role, if it is a super administrator it has all permissions
There are actually two test points here. One is whether it can be related to the context normally. Answers that are incorrect are meaningless. The second is the process of correctly understanding the requirements and realizing them. Let’s take a look at its answer.
Certainly! Here is an implementation that includes a super administrator role, which has all permissions:
```go
package main
import "fmt"
// Define roles
const (
RoleGuest = "guest"
RoleUser = "user"
RoleAdmin = "admin"
RoleSuperAdmin = "superadmin"
)
//User struct to hold user information
typeUser struct {
Name string
Role string
}
// Permissions struct to define allowed actions for a role
typePermissions struct {
CanView bool
CanEdit bool
CanDelete bool
}
// RolePermissionsMap maps roles to their respective permissions
var RolePermissionsMap = map[string]Permissions{
RoleGuest: {
CanView: true,
CanEdit: false,
CanDelete: false,
},
RoleUser: {
CanView: true,
CanEdit: true,
CanDelete: false,
},
RoleAdmin: {
CanView: true,
CanEdit: true,
CanDelete: true,
},
RoleSuperAdmin: {
CanView: true,
CanEdit: true,
CanDelete: true,
},
}
// CheckPermission checks if a user has permission for a specific action
func CheckPermission(user User, action string) bool {
permissions := RolePermissionsMap[user.Role]
switch action {
case "view":
return permissions.CanView
case "edit":
return permissions.CanEdit
case "delete":
return permissions.CanDelete
default:
return false
}
}
func main() {
//Create some users
user1 := User{"John", RoleGuest}
user2 := User{"Alice", RoleUser}
user3 := User{"Admin", RoleAdmin}
user4 := User{"SuperAdmin", RoleSuperAdmin}
//Example usage
fmt.Println(user1.Name, "can view:", CheckPermission(user1, "view")) // Output: true
fmt.Println(user2.Name, "can delete:", CheckPermission(user2, "delete")) // Output: false
fmt.Println(user3.Name, "can edit:", CheckPermission(user3, "edit")) // Output: true
fmt.Println(user4.Name, "can delete:", CheckPermission(user4, "delete")) // Output: true
}
```
In this implementation, the super administrator has all permissions, so it will return `true` for all actions.
Very good, the context association is normal, there is no situation where the newly generated content has nothing to do with the historical content, and the corresponding super administrator requirements are successfully implemented.
After successfully realizing the initial requirements and new requirements, should we test its test case implementation?
/code Generate corresponding test cases based on the above code
package main
import (
"fmt"
"testing"
)
func TestCheckPermission(t *testing.T) {
user1 := User{"John", RoleGuest}
user2 := User{"Alice", RoleUser}
user3 := User{"Admin", RoleAdmin}
user4 := User{"SuperAdmin", RoleSuperAdmin}
testCases := []struct {
userUser
action string
expectedValue bool
}{
{user1, "view", true}, // Guest user can view
{user1, "edit", false}, // Guest user can't edit
{user2, "view", true}, // User can view
{user2, "edit", true}, // User can edit
{user2, "delete", false}, // User can't delete
{user3, "view", true}, // Admin can view
{user3, "edit", true}, // Admin can edit
{user3, "delete", true}, // Admin can delete
{user4, "view", true}, // SuperAdmin can view
{user4, "edit", true}, // SuperAdmin can edit
{user4, "delete", true}, // SuperAdmin can delete
{User{"Unknown", "unknown"}, "view", false}, // Unknown user role
{user1, "unknown", false}, // Unknown action
}
for _, testCase := range testCases {
result := CheckPermission(testCase.user, testCase.action)
if result != testCase.expectedValue {
t.Errorf("Failed test case for user '%s' and action '%s'. Expected: %t, got: %t",
testCase.user.Name, testCase.action, testCase.expectedValue, result)
}
}
}
Yes, the corresponding test cases have been completed and the test cases have passed successfully.
From initial Demo implementation to requirement changes and final test case writing. DevChat can all do our job very well, with correct understanding of semantics and correct association of context, all of which are excellent. After experience, it still has good product features, supporting multiple large language models, from overseas ChatGPT to domestic large Mars models, all have corresponding access, like an aggregated treasure chest, for developers People surprise.
Introduction to the exclusive benefits for KOL fans. KOLs who successfully participate in the competition will have an exclusive red envelope redemption code. Before November 31, fans can use the invitation code to redeem a balance of 10 yuan on Devchat.
Download official website: https://www.devchat.ai