Kamer's Personal Blog

Java Optional Guide

Sat, 02 May 2020 17:13:16 +0300

1. What is the purpose of Optional Class?

If you have been into coding for a while, you should have encountered Null Pointer Exception before. If you try to use a reference type that doesn’t point anything in the memory, you get NullPointerException. This sentence may be complicated, see the example below:

String name = null;
System.out.println(name);

I declared a name variable that points to null and tried to print it. This will throw NullPointerException since name variable doesn’t show anywhere in the memory. Generally, you do not assign null to a variable and print it. But there are many cases you may accidentally see this runtime exception. If you want to see all cases read docs.

Programmers are used to deal with this exceptions by null checking. (if(name != null)). But this makes the code ugly and a programmer cannot be sure if there is a possibility of null return from a method he/she called. Many of the programming languages have different methods to deal with Null Pointer Exception. Java Optional is one of them since Java 8. Optionals are objects that may have null or non-value inside. You can check an optional object whether the value is null or not and get the value if it is not. Returning an Optional from a method is simply saying “check the returning object since it can have null value."

2. Creating Optional Objects

2.1 Empty Optional (`empty()`)

Returning an empty optional is equivalent to returning null before Java 8. This can be done with the static empty() method.

Optional<String> optionalName = Optional.empty();

Never check an optional if it is empty by comparing it == Optional.empty(); There are different methods to check an Optional.

2.2 Optional with a value (`of()`)

Returning an optional with a value inside it is equivalent to returning the object itself before Java 8.

Optional<String> optionalString = Optional.of("Kamer");

of() method is not nullable. If you pass null, you will get NullPointerException.

2.3 Optional with a nullable value (`ofNullable()`)

This method is for nullable values. You can pass any value whether it is null or

Optional<String> optionalString = Optional.ofNullable(null);

Optional<String> optionalString = Optional.ofNullable("Kamer");

3. Checking Optionals

3.1 Checking with `isPresent();`

It does what the name suggests. Returns boolean value.


if (optionalName.isPresent()){
    ...
    ...
}

3.2. Checking with `isEmpty();`

Opposite of isPresent(). This method can be used since Java 11.


if (optionalName.isEmpty()){
    ...
    ...
}

4. Getting Value From Optional

As you see, Optional is a container that holds some value. After checking an Optional with the methods above, you can get the value with get() method.

if (optionalUser.isPresent()){
    return optionalUser.get();
} else {
    throw new UserNotFoundException();
}

5. Default Values and Actions

Sometimes we may return a default value, produce a value or do some actions in case of any empty Optional.

5.1 Get a default value with `orElse()`

It returns the value if optional has a value and returns the default value if not so.

String userName = optionalUsername.orElse("admin");

5.2 Throw `NoSuchElementException` with `orElseThrow()`

Title is clear. This method is available since Java 10.

...
return optionalUsername.orElseThrow();

5.3 Throw any exception with `orElseThrow()`

You can throw any exception you want if Optional is empty.

...
return optionalUsername.orElseThrow(UserNotFoundException::new);

...
return optionalUsername.orElseThrow(() -> new UserNotFoundException("..."));

5.4 Get a default value with a Supplier with `orElseGet()`

Supplier is the function that takes no value and produces a result. See java.util.function.Supplier.

...
return optionalUsername.orElseGet(String::new);

5.5 Return a default Optional with `or()`

This function also takes Supplier function as parameter. or() returns the Optional or the default Optional that supplier function produces. This method is available since Java 9.

...
return optionalUsername.or(() -> Optional.of("admin"));

6. Conditional Actions with Lambda Expressions

6.1 `ifPresent()`

This method takes Consumer<? super T> as parameter. See java.util.function.Consumer.

optionalUsername.ifPresent(System.out::println);

6.2 `ifPresentOrElse()`

This method takes two parameters. Consumer<? super T> and Runnable. It is available since Java 9.

optionalUsername.ifPresentOrElse(
    System.out::println,
    () -> System.out.println("No Username."));

7. Filtering the Value with `filter()`

This method takes a predicate and an Optional is returned based on the result of the predicate. If predicate returns true Optional has the value. Otherwise, empty Optional is returned.

...
return optionalUsername.filter(String::isBlank);

8. Mapping Values

8.1 `map()`

It returns an Optional. If Optional is not empty, it has the state after mapping function is applied.

Optional<String> optionalUsername = optionalResult.map(String::trim);

8.2 `flatMap()`

It’s like map() but this time the result is flattened. This means if there is more than one level nested Optional, it converts it to one-level. See the example.

Optional<String> optionalUsername = Optional.ofNullable("Kamer");

Optional<Object> mapOptional
    = optionalUsername.map(username -> Optional.of(username.toLowerCase()));

This map() return will return the String inside an Optional which is inside another Optional. Optional<Optional<String>>

Optional<String> optionalUsername = Optional.ofNullable("Kamer");

Optional<Object> flatMapOptional
    = optionalUsername.flatMap(s -> Optional.of(s.toLowerCase()));

But flatMap() flattens the result and it returns just Optional<String>

References

Spring Boot User Registration and Login

Sat, 21 Mar 2020 20:30:00 +0000

Update 2020/05/02: I removed useless csrf().disabled() config and CustomAuthenticatorProvider class. Also, I changed Optional logic and used orElseThrow() method. Thanks @gokcensedat and @utkuozdemir for their valuable comments.

Hello! In this article, I’ll explain how to register users to your application, how to send confirmation mail and handle user logins. My main resource will be official docs and you can access Github repository at the end of the article. I will not explain exception handling parts since our main subject is different.

Table of Contents

Requirements

You need to know Java and must have developed at least one Spring project to understand this article.

1. Creating a project with Spring Initialzr

Create a project with Spring Web, Lombok, Thymeleaf, Spring Security, Java Mail Sender, H2 and Spring Data JPA dependencies with Spring Initialzr. You can use your IDE’s plugin or https://start.spring.io/.

2. Create User entity

Create an entity package and UserRole enum inside the package. We will add ADMIN and USER values for now but you can add more according to your needs.

enum UserRole {

    ADMIN, USER
}

Now, create a User class. This class has to implement UserDetails interface. This interface has basic user methods. You can see an implementation in org.springframework.security.core.userdetails.User class. You can also extend this class and add your own fields. I will not extend this class because I want to show the whole process. So, let’s create a few fields, implement the required methods and fill them.

@Getter
@Setter
@Builder
@EqualsAndHashCode
@NoArgsConstructor`
@AllArgsConstructor
@Entity(name = "Users")
public class User implements UserDetails {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    private String surname;

    private String email;

    private String password;

    @Builder.Default
    private UserRole userRole = UserRole.USER;

    @Builder.Default
    private Boolean locked = false;

    @Builder.Default
    private Boolean enabled = false;

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {

	final SimpleGrantedAuthority simpleGrantedAuthority = new SimpleGrantedAuthority(userRole.name());
	return Collections.singletonList(simpleGrantedAuthority);
    }

    @Override
    public String getPassword() {
	return password;
    }

    @Override
    public String getUsername() {
	return email;
    }

    @Override
    public boolean isAccountNonExpired() {
	return true;
    }

    @Override
    public boolean isAccountNonLocked() {
	return !locked;
    }

    @Override
    public boolean isCredentialsNonExpired() {
	return true;
    }

    @Override
    public boolean isEnabled() {
	return enabled;
    }
}

We will not use expired field for this example, so always return true and we will also use email instead of username. So return email from getUsername() method. You can deduce others from the names.

3. Create UserService

Create a user package and UserService class inside the package. Then, implement UserDetailsService which requires you to implement loadByUsername(). But here’s important, we will use email instead of username. So, this method will take email as parameter and return the user. To achieve this, we need to interact with database, so we need a repository. Create a UserRepository interface inside the same package and add findByEmail() method.

interface UserRepository extends CrudRepository<User, Long> {

    Optional<User> findByEmail(String email);
}

Now, turn back to UserService, add UserRepository as a field and complete the method. UserService will be as below.

@Service
@AllArgsConstructor
public class UserService implements UserDetailsService {

    private final UserRepository userRepository;

    @Override
    public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {

	final Optional<User> optionalUser = userRepository.findByEmail(email);

	if (optionalUser.isPresent()) {
	    return optionalUser.get();
	}
	else {
	    throw new UsernameNotFoundException(MessageFormat.format("User with email {0} cannot be found.", email));
	}
    }
}

4. Create ConfirmationToken class

We will create a token and a unique link for every user registration and send them with email. Create a ConfirmationToken class inside user package and add these fields:

@Entity
@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
class ConfirmationToken {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String confirmationToken;

    private LocalDate createdDate;

    @OneToOne(targetEntity = User.class, fetch = FetchType.EAGER)
    @JoinColumn(nullable = false, name = "user_id")
    private User user;

    ConfirmationToken(User user) {
	this.user = user;
	this.createdDate = LocalDate.now();
	this.confirmationToken = UUID.randomUUID().toString();
    }
}

This is a simple entity as you see. Since every user will have a single token, we create a OneToOne relation. createdDate field will be used to check if the token is expired or not.

5. User registration process

I want you to experience a real-like development process instead of writing all the methods and classes. So let’s think of the process step by step.

Take user information with the registration form.
Encode the password with BCryptPasswordEncoder and create the user with enabled=false value as we set default in User class.
Create a ConfirmationToken and assign this token to the user.
Create a unique url with this token and send it via email.
When the user clicks the link change enabled field to true for that user.
Delete the token.

So, we will create ConfirmationTokenRepository and ConfirmationTokenService before signUpUser() method. Because we need this method in signing-up process.

@Repository
interface ConfirmationTokenRepository extends CrudRepository<ConfirmationToken, Long> { }

@Service
@AllArgsConstructor
class ConfirmationTokenService {

    private final ConfirmationTokenRepository confirmationTokenRepository;

    void saveConfirmationToken(ConfirmationToken confirmationToken) {

	confirmationTokenRepository.save(confirmationToken);
    }
}

Now, go to UserService class and create signUpUser() method.

void signUpUser(User user) {

    final String encryptedPassword = bCryptPasswordEncoder.encode(user.getPassword());

    user.setPassword(encryptedPassword);

    final User createdUser = userRepository.save(user);

    final ConfirmationToken confirmationToken = new ConfirmationToken(user);

    confirmationTokenService.saveConfirmationToken(confirmationToken);

}

6. Create confirmation methods

We have user registration process. Now, we need confirmation process. First of all, create the method that will delete token after confirmation.

void deleteConfirmationToken(Long id){

    confirmationTokenRepository.deleteById(id);
}

Then, create confirmUser() method.

void confirmUser(ConfirmationToken confirmationToken) {

    final User user = confirmationToken.getUser();

    user.setEnabled(true);

    userRepository.save(user);

    confirmationTokenService.deleteConfirmationToken(confirmationToken.getId());

}

7. Spring Mail config

I use application.yml instead of application.properties. (see this) Here’s the Spring Mail config for Gmail. If you use 2-factor, you have to create a password for application. (see this)

spring:
  mail:
    host: smtp.gmail.com
    port: 587
    username: <MAIL_ADDRESS>
    password: <PASSWORD>
    properties:
      mail:
	smtp:
	  auth: true
	  starttls:
	    enable: true
	  connectiontimeout: 5000
	  timeout: 3000
	  writetimeout: 5000

8. Create EmailService

Create an EmailService class inside user package and create sendEmail() method inside it.

@Service
@AllArgsConstructor
public class EmailSenderService {

    private JavaMailSender javaMailSender;

    @Async
    public void sendEmail(SimpleMailMessage email) {
	javaMailSender.send(email);
    }
}

Now, create the sendConfirmationMail() inside UserService.

void sendConfirmationMail(String userMail, String token) {

    final SimpleMailMessage mailMessage = new SimpleMailMessage();
    mailMessage.setTo(userMail);
    mailMessage.setSubject("Mail Confirmation Link!");
    mailMessage.setFrom("<MAIL>");
    mailMessage.setText(
	    "Thank you for registering. Please click on the below link to activate your account." + "http://localhost:8080/sign-up/confirm?token="
		    + token);

    emailSenderService.sendEmail(mailMessage);
}

9. Spring Security Configuration

We created the whole process related to Spring Security. Now we will set configuration for all. Create WebSecurityConfig and WebConfig inside config package.

@Configuration
@AllArgsConstructor
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    private final UserService userService;

    private final BCryptPasswordEncoder bCryptPasswordEncoder;

    @Override
    protected void configure(HttpSecurity http) throws Exception {

	http
	    .authorizeRequests()
	    .antMatchers("/sign-up/**", "/sign-in/**")
	    .permitAll()
	    .anyRequest()
	    .authenticated()
	    .and()
	    .formLogin()
	    .loginPage("/sign-in")
	    .permitAll();
    }

    @Autowired
    public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
	auth.userDetailsService(userService)
		.passwordEncoder(bCryptPasswordEncoder);
    }

}

@Configuration
public class WebConfig {

      @Bean
      public BCryptPasswordEncoder bCryptPasswordEncoder() {

	      return new BCryptPasswordEncoder();
      }
}

These configuration classes simply set sign-in and sign-up pages, set encoder and authentication provider. You can learn them with this great article.

10. Create controller and pages

We have all we need for an application except HTML pages. We will create those and make them accessible with controller.

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="en">
<head>
    <title>Spring Boot User Authentication</title>
</head>
<body>
<form role="form" th:action="@{/sign-in}" th:method="post">
    <label>Username</label>
    <input type="text" id="username" name="username">

    <label>Password</label>
    <input type="password" id="password" name="password">

    <input type="submit">
</form>
</body>
</html>

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="en">
<head>
    <title>Spring Boot User Authentication</title>
</head>
<body>
<form role="form" th:action="@{/sign-up}" th:method="post" th:object="${user}">
    <label>Name</label>
    <input type="text" id="name" name="name" th:field="*{name}">

    <label>Surname</label>
    <input type="text" id="surname" name="surname" th:field="*{surname}">

    <label>Email</label>
    <input type="text" id="email" name="email" th:field="*{email}">

    <label>Password</label>
    <input type="password" id="password" name="password" th:field="*{password}">

    <input type="submit">
</form>
</body>
</html>

@Controller
@AllArgsConstructor
public class UserController {

    private final UserService userService;

    private final ConfirmationTokenService confirmationTokenService;

    @GetMapping("/sign-in")
    String signIn() {

	return "sign-in";
    }

    @GetMapping("/sign-up")
    String signUp() {

	return "sign-up";
    }

    @PostMapping("/sign-up")
    String signUp(User user) {

	userService.signUpUser(user);

	return "redirect:/sign-in";
    }

    @GetMapping("/confirm")
    String confirmMail(@RequestParam("token") String token) {

	Optional<ConfirmationToken> optionalConfirmationToken = confirmationTokenService.findConfirmationTokenByToken(token);

	optionalConfirmationToken.ifPresent(userService::confirmUser);

	return "/sign-in";
    }

}

Conclusion

If you have followed the article properly, you can go to http://localhost:8080/sign-up to sign up. But do not forget, it is not a production ready application since we didn’t create validations(including token expiration) and provide proper exception handling. If you want to learn about validations you can see https://medium.com/@kamer.dev/validations-in-spring-boot-4f15598c3d6a.

Github Repository: https://github.com/kamer/spring-boot-user-registration

How to debug your code in IntelliJ

Sat, 21 Mar 2020 17:05:00 +0000

Debugging code can be difficult sometimes for newbies but it is not as difficult as it seems. In this post I will explain IntelliJ Debugging interface starting from the basics. I will not cover all the features. They are the ones that I use most.

Table of Contents

Requirements

There is no requirements for this.

My Motivation

I used to debug my code with System.out.println(); and it was OK for me. I didn’t have any complaints about it because I thought using debugging interface does the same thing with a fancy label. Last year I did an internship and one day, I forgot to remove System.out.println(); in my pull request. It was rejected in the code review and my mentor taught me the basics of debugging. It was a good experience for me although I had difficulty giving up my bad habit. Now, I’ve completely quitted System.out.println(); and explored some much about debugging. It’s time to share what I’ve learnt.

1. Setting breakpoints

The most important part of debugging is breakpoints. Breakpoint is the place where you want to pause your program for debugging purposes. When your program pauses at somewhere, you can see many properties of your current scope. There are four types of breakpoints.

1.1 Line Breakpoint

This is the most used one of all. It pauses your program before the marked line is executed. Just click on the gutter near line number to set your breakpoint. There is only one requirement, the line should be executable.

1.2 Method Breakpoint

You can pause the program to see the entering and exiting values of a method. This breakpoint pauses the program twice. Click the gutter where the method is declared. You can also click the class declaration to set breakpoint to the constructor.

1.3. Field Watchpoint

This is used for tracking all interactions for a field. Set the breakpoint on the field declaration. Your program will pause every time you interact with that field.

1.4. Exception Breakpoint

When you set an exception breakpoint, your program pauses whenever an exception is thrown. It’s global and not dependent on your source code. So, you don’t set it with gutter clicks like previous ones. Open View Breakpoints window with Ctrl+Shift+F8 or View Breakpoints button in Debug window. You can choose Any Exception under Java Exception Breakpoints or add a specific exception with the + icon or Alt+Insert.

You can add all types of breakpoints in this window. But gutters are more convenient for others.

1.5 Conditional Breakpoint

No need to explain, it does what the name says. After setting a breakpoint right click on the icon you will see basic condition input. You can write a condition as if you are writing an if condition. It will pause if the condition returns true.

IntelliJ provides different types of conditions and filters but I will not explain them. See IntelliJ docs.

2. Debug Window

2.1 Step Functions

You can see the step functions above. These buttons are taken from Debug window. You can use Alt+5 to open Debug window if not visible. Let’s dive into the details of these step functions.

Step Over: When you step over a line, you execute it and pause before the next line is executed.

Step Into: If you step into a line, there are two possibilities. If there is a function call debugger go to that function and execute it step-by-step. Otherwise, it will behave like Step Over since there’s nothing to step into.

Force Step Into: In some cases debugger ignores the step into option and behaves like step over. You can force it to step into with it. For instance, debugger ignores stepping into `String string = new String(“Hello World!");` but if you force, you will see String implementation.

Step Out: You go back where you called the current function. To continue with the example above, when you click Step Out inside String implementation then you go back where you call new String();.

Drop Frame: It’s going one step backward. As I stated before in this article, when your program pauses at some point, you see the current stack frame. You go to previous stack frame with it. But do not confuse, you don’t go back in time, you just go one step backward. It won’t undo your last operation.

Run to Cursor: It will take the debugger where your cursor is regardless of the breakpoints.

2.2 Debugger Control Buttons

These are debugger control buttons placed leftmost part of the debugger window.

Rerun: It does what it says.

Resume Program: It resumes the program from where it is paused until a breakpoint pauses it again.

Pause Program: It pauses the running program but does not provide you all the functionalities that breakpoints have.

Stop: It stops the running program as you might guess.

View Breakpoints: It will show a window where you can see all set breakpoints, set/remove breakpoints and define conditions.

Mute Breakpoints: It will deactivate all set breakpoints.

2.3 Tracing Variables

You write a method or any piece of code and expect it to work as you planned but things don’t go well. If you trust your algorithm, the best option is to trace every change in your code through the stack frame. Just set a breakpoint and see every change.

Think of a method that you give a ticket date in String as parameter and it returns you whether the ticket is expired. You think something is wrong according and wanted to debug your method step by step. You might have parsed the String date wrong or made a mistake while calculating the days between two dates. Just put breakpoints in your method and inspect changes in variables. I created a simple dummy method and set the breakpoint at the end of the method to see all variables' last state.

You see dateInput variable and it is parsed as “2019-03-10”. Then you check front-end and see that the date is actually sent as “dd-M-yyyy” but parsed like “M/dd/yyyy”. So the problem is solved quickly. This is a dummy example to see the basic purpose of tracing variables. Real-life scenarios will be more useful.

2.4 Evaluating Expressions and Setting Values Manually

These are also good features. You can test your paused application with different values and take your inspection further. If you look at a variable and say “what would happen if it were …?", this means you need one of these features. Evaluate Expression also provides more than just setting values.

To set a value basically, right-click on the variable, select Set Value (F2) and write the new value.

If you want to have more advanced capabilities or evaluate a Java expression, right-click on the variable and select Evaluate Expression (Alt+F8). You can run your expression in that window.

Think of the last dummy example above in 2.3 Tracing Variables. You wanted to see if your method would work correctly when you change your parser. Change the date before logic and see what happens.

You can also declare a new variable and add it to your watches. Result is shown under the expression input as you see.

My main resource is IntelliJ docs. You can check this link for further information.

FasterXML/jackson Tips for JSON in Java

Fri, 06 Mar 2020 23:30:00 +0000

Introduction

All my examples will be in a Spring Boot project that has Web and Lombok dependencies. I will not list all features and explain them one by one like a documentation. Instead, I will ask some questions and answer them. I hope you will find your questions! If not so, you can ask me on Twitter or e-mail.

Table of Contents

What is Jackson?

This article is not a zero-to-hero-like article. So, I will not start from basics but introduce Jackson with a few words. Because you may have been using Jackson library without knowing you do so. Jackson is the most widely used JSON processing library for Java. It has 3 core modules (jackson-core, jackson-annotations, jackson-databind), third-party modules for different integrations. You may have been using them because spring-boot-starter-web includes these three modules(and more) and Jackson is registered as default object mapper library. This is why you can produce JSON data by just returning Java object in your controller in your Spring application.

Q1: How to create a Java POJO for any JSON input?

Perhaps, this is the simplest question that comes to mind. Let’s see an example JSON:

{
  "title": "2019-2020 Algorithms Final Exam",
  "lecture": "Algorithms",
  "examDate": "2020-03-04T09:00:00.000Z",
  "studentNumber": 75,
  "questions": [
    {
      "questionNumber": 1,
  "question": "What is an asymptotic notation?"
  },
  {
      "questionNumber": 2,
  "questions": "Find worst case for insertion sort?"
  },
  {
      "questionNumber": 3,
  "question": "Which algorithm would you choose to sort 1m numbers, why?"
  }
  ]
}

Let’s analyze this JSON. This is an object that has title (string), lecture (string), examDate (date), studentNumber (numeric value, int is the best option for this case.) and questions (array) fields. So, we should map this JSON to a Java object that has the same fields. All fields are OK but questions array has an object type that has questionNumber(numberic value, int) and question (string) fields.

First of all, create a Question object as below:

@Getter
@Setter
@ToString
class Question {

   private Integer questionNumber;

   private String question;

}

Then, create Exam object.

@Getter
@Setter
@ToString
public class Exam {

   private String title;

   private String lecture;

   private LocalDateTime examDate;

   private Integer studentNumber;

   private List<Question> questions;

}

That’s all. Finally, create a controller.

@PostMapping("/question-one")
ResponseEntity<Void> questionOne(@RequestBody Exam exam) {
   log.info("Parsed object: {}", exam);
   return ResponseEntity.ok().build();
}

Now, send JSON with any method you like.

We mapped JSON array as List in our POJO. This is not a must, we can also use Java Array (Question[]), Collection<>, Set<>, Iterable<> and any other type that implements Iterable<>.

Q2: How to use different field names in POJO to map JSON?

In Q1 we named our fields according to given JSON. But this is not a must. We can use different names with many different options. But I will explain only two of them. So let’s create an example JSON:

{
  "productTitle": "TWSBI ECO Fountain Pen White M Nib",
  "productPrice": "30.00",
  "productCategoryId": 13,
  "productTagId": 235
}

As you see, there is a JSON object -let’s call it product- and it has 4 fields. Creating a POJO with the same field names are possible. But removing product... prefix is better.

Option 1

Create a POJO as below:

@Getter
@Setter
@ToString
public class Q2ProductOptionOne {

    @JsonAlias("productTitle")
    private String title;

    @JsonAlias("productPrice")
    private String price;

    @JsonAlias("productCategoryId")
    private Integer categoryId;

    @JsonAlias("productTagId")
    private Integer tagId;
}

@JsonAlias annotation makes possible to define multiple options for a property. So @JsonAlias("productTitle") annotation catches productTitle key in JSON. But don’t forget, this annotation creates alternatives only. Actual property name doesn’t change.

This option works perfectly but not the best option. Because what we want is to change the property name not to create alternatives.

Option 2

@JsonProperty annotation is the other option. This will change the property name:

@Getter
@Setter
@ToString
public class Q2ProductOptionTwo {

    @JsonProperty("productTitle")
    private String title;

    @JsonProperty("productPrice")
    private String price;

    @JsonProperty("productCategoryId")
    private Integer categoryId;

    @JsonProperty("productTagId")
    private Integer tagId;

}

We can use these two annotations at the same time. @JsonProperty will change the actual name and @JsonAlias will add other options.

You can set an access option on @JsonProperty. This will provide you some options such as changing the property name on deserialization/serialization/both.

Q3: How to deserialize nested JSON objects?

In a standard JSON communication, you are likely to encounter nested objects inside JSON. In Q1 we deserialized a JSON input with multiple classes. But there are other options.

{
    "title": "TWSBI ECO Fountain Pen White M Nib",
    "price": "30.00",
    "taxonomy": {
	"categoryId": 13,
	"tagId": 235
    }
}

Option 1

First option is to map nested object to a Map. This is very easy.

@Getter
@Setter
@ToString
public class Q3ProductOptionOne {

    private String title;

    private Float price;

    private Map<String, String> taxonomy;

}

Jackson will initialize this map with categoryId and tagId keys.

Option 2

@Getter
@Setter
@ToString
public class Q3ProductOptionTwo {

    private String title;

    private Float price;

    private Integer tagId;

    private Integer categoryId;

    @JsonProperty("taxonomy")
    @SuppressWarnings("unchecked")
    private void taxonomyDeserializer(Map<String, Object> taxonomy) {
	this.tagId = (Integer) taxonomy.get("tagId");
	this.categoryId = (Integer) taxonomy.get("categoryId");
    }
}

This option looks like the previous option. But it’s better I think. Because we does not use map class as nested object. Instead, we give this nested map to a private method annotated with @JsonProperty and @SuppressWarnings. Then extract values from map and set to fields.

Option 3

This option is a different question. So, check Q4 for this.

Q4: How to create a custom deserializer?

There may be some cases that you don’t want to use annotations or these annotations are not enough for your development. So, you can create your own deserializer that you receive raw JSON and export POJO, then, register it to overwrite default deserializer. Let’s create a JSON that has nested objects.

{
    "applicant": {
	"name": "Joss",
	"surname": "Stone"
    },
    "application": {
	"announcementId": 2,
	"givenInput": {
	    "profileLink": "<https://dummypage.com>",
	    "cvFileName": "myAwesomeCv.pdf"
	}
    }
}

We can deserialize it as it is explained in Q3. But creating a custom deserializer is another option.

This is our POJO:

@Getter
@Setter
@Builder
@ToString
public class Application {

    private String applicationFullName;

    private Integer announcementId;

    private String applicantProfileLink;

    private String cvName;
}

And this is deserializer:

public class ApplicationDeserializer extends StdDeserializer<Application> {

    public ApplicationDeserializer() {
	this(null);
    }

    public ApplicationDeserializer(Class<?> vc) {
	super(vc);
    }

    @Override
    public Application deserialize(JsonParser jp, DeserializationContext ctxt) throws IOException, JsonProcessingException {

    final JsonNode jsonNode = jp.getCodec().readTree(jp);
    final JsonNode applicantNode = jsonNode.get("applicant");
    final JsonNode applicationNode = jsonNode.get("application");

    final String name = applicantNode.get("name").asText();
    final String surname = applicantNode.get("surname").asText();
    final Integer announcementId = applicationNode.get("announcementId").asInt();

    final JsonNode givenInputNode = applicationNode.get("givenInput");
    final String profileLink = givenInputNode.get("profileLink").asText();
    final String cvFileName = givenInputNode.get("cvFileName").asText();

    return Application.builder()
		      .applicationFullName(name + " " + surname)
		      .announcementId(announcementId)
		      .applicantProfileLink(profileLink)
		      .cvName(cvFileName)
		      .build();
    }
}

All elements are JsonNode in this deserialization process. If you chain a method such as asText(), asInt(), they are converted into desired form. Otherwise they are treated as JsonNode. You can perform all kinds of validations and manipulations also.

Lastly, let’s register deserializer class in our POJO class with the annotation below:

@JsonDeserialize(using = ApplicationDeserializer.class)

Q5: How to deserialize enum values?

Deserializing enum values is easy. You can do it without a tutorial. But there are different options. First of all, create an enum class.

public enum ContainerStatusOptionOne { RUNNING, FAILED, PENDING, REMOVING }

Then, create a POJO that has this enum as a field.

@Getter
@Setter
@ToString
public class Container {
    private String containerTitle;
    private ContainerStatus containerStatus;
}

Option 1

This is option is the first that comes to mind. Just send the name of the enum value.

{
    "containerTitle": "Stage",
    "containerStatus": "RUNNING"
}

But don’t forget, this option works case sensitive. If you send running as a value, you get HttpMessageNotReadableException.

Option 2

This option is as easy as the first option but personally, I don’t find it useful. When you send numeric values for enum, Jackson deserializes it also. RUNNING is 0 for our example and REMOVING is 3. So:

{
    "containerTitle": "Stage",
    "containerStatus": 0
}

is the same as the example above.

Option 3

There are some situations that you may work with 3rd party services and you cannot change your request body according to your POJO. For instance, 3rd party service sends lowercase values for enums. Jackson provides an annotation for this also. We need to change enum values as below:

public enum ContainerStatusOptionTwo {
    @JsonProperty("running") RUNNING,
    @JsonProperty("failed") FAILED,
    @JsonProperty("pending") PENDING,
    @JsonProperty("removing") REMOVING
}

Now, Jackson will look for running, failed, pending and removing as input. So, sending the JSON below works:


{
    "containerTitle": "Stage",
    "containerStatus": "running"
}

References

Jackson Documentation
https://www.concretepage.com/jackson-api/jackson-jsonproperty-and-jsonalias-example
https://www.baeldung.com/jackson-nested-values

Github Repo: https://github.com/kamer/jackson-tips-for-json-in-java

Thymeleaf Crash Course

Mon, 24 Feb 2020 20:45:00 +0000

Hello! In this article I will explain what template engine is and give you a crash course about Thymeleaf with Spring Boot. My main resources are official documentations which are published under the title of Thymeleaf 3.0 and Thymeleaf+Spring. Github repo is also available at the end of the article.

1. Theoretical

1.1 What is Thymeleaf?

You can find the shortest and -I think- the best explanation at Thymeleaf’s docs:

Thymeleaf is a modern server-side Java template engine for…

Keywords are server-side and Java template engine. Rest of the definition is not important at this point. Let’s look at template engine.

Template engine is a language-independent software that processes given template and produces a result by filling it with data. There are several template engines for different languages. For instance, there is a page template for Jekyll below:

Jekyll uses Liquid template language. When you read the example, you can find out that post is an object that has title, content and tags[] fields. You can render this page in your mind.

Once you have a clear definition of template and template engine you can comprehend the difference between client-side and server-side rendering. At client-side rendering, client receives the template with some data(XML, JSON etc.) and renders them at the client-side. But when you use server-side templating, template and the data is processed at the server-side and the final result is sent to client.

Thymeleaf supports 6 kinds of templates which are HTML, XML, Text, JavaScript, CSS and RAW.

Thus, we have an idea of Thymeleaf. Let’s solidify our understanding with a brief definition of process.

We will prepare a template that extends simple HTML syntax; give Java objects and the template to template engine. Template engine will process these inputs and create an HTML file.

1.2 Thymeleaf Standart Dialect

If you don’t want to learn the details you can omit this section but I recommend you to learn terminology of Thymeleaf. This whole section also exists in the documentation but I want to explain them with my own sentences.

Let’s go with the documentation again:

An object that applies some logic to a markup artifact is called a processor, and…

This sentence seems so simple but let’s clarify our understanding by explaining the term markup. Yeah, I know, this is not a mystery for the people who have written at least a few lines with HTML but most of the people don’t know what it is. Markups are symbols and texts that we insert to a document to format its content. For instance when you type <h1>Thymeleaf</h1> in a HTML document, you define it as the highest level heading. That’s why we call it markup language. After this definition, the sentence from the documentation is more clear when you read again: “An object that applies some logic to a markup artifact is called a processor, and…"

These processors are combined and called dialects. Thymeleaf provides us Standart Dialect which is mostly enough for basic processing but in case not, you can create your own processors and dialects.

2. Practical

As I specified at the beginning, this article will be based on Thymeleaf in a Spring Boot app. Therefore, I will explain both Standard Dialect and SpringStandard Dialect. Now, go to https://start.spring.io/ or use IDE plugins to create the project. Spring Web and Thymeleaf dependencies are enough.

2.1 Folder Hierarchy

When you create a Thymeleaf dependent project with Spring Initalzr, this is what you get by default:

Put your static content (e.g. css, js, img) in static folder and templates in templates folder. But it’s not a must. You can change this default also.

Best approach is to set spring.resources.static-locations property in application.properties file. For instance:

spring.resources.static-locations=file:/awesome/path

spring.resources.static-locations=classpath:/resources/my_static_content

You can change templates folder as well.

2.2 Syntax

2.2.1 Simple Expressions

spring.thymeleaf.prefix=classpath:/my_templates/

Variable Expressions(${...})

When you send data in model object with a controller, you can process them with this syntax.
```
<p> Hello <span th:text="${username}"></span> </p>
```
We will cover th:... attributes later. Just focus on ${...} part.

Selection Variable Expressions(*{...})

This is another expression to process variables and more convenient for some cases. Instead of picking an object from whole model context, you can select from particular selected context. Let’s clarify this with an example:
```
<div>
    <h3 th:text="${post.title}"></h3>
    <p th:text="${post.excerpt}"></p>
</div>
```
This is standard variable expression. It’s possible to use selection variable expression syntax:
```
<div th:object="${post}">
    <h3 th:text="*{title}"></h3>
    <p th:text="*{excerpt}"></p>
</div>
```

Message Expressions(#{...})

Best way to extract static texts to achieve i8n is using MessageSource. You can process these texts with this syntax. For instance if you want to process the text below:
```
greeting.title=Message Expressions
```
You can write:
```
<h1 th:text="#{greeting.title}"></h1>
```
You can also pass variables to this texts:
```
greeting.text=Hello {0}! How are you today?
```
with:
```
<p th:text="#{greeting.text(${username})}"></p>
```

Link URL Expressions(@{...})

There are some attributes that needs URL as input. Thymeleaf provides a good syntax for URLs.

You can;
- create absolute URLs:
```
<a th:href="@{https://google.com}">...</a>
```
- create Context-relative URLs:
```
<a th:href="@{/comments}">...</a>
```
- Server-relative URLs:
```
<a th:href="@{~/posts}">...</a>
```
- Protocol-relative URLs:
```
<a th:href="@{//google.com}">...</a>
```
- use variables inside URLs with expression preprocessing which process the expression between “__ __” :
```
<a th:href="@{/users/__${userId}__/posts}">...</a>
```
- define URL parameters:
```
<a th:href="@{/posts(page=${pageNumber}, tag='java')}"></a>
```

Fragment Expressions(~{...})

I think its much harder than it should be for a crash course.

2.2.2 Constructing Texts

Thymeleaf provides a good syntax to construct texts. First one is + operator.

<span th:text="'Hello' + ${username} + '! How are you today?'"></span>

You can do the same with literal substitutions:

<span th:text="|Hello ${username}!How are you today?|"></span>

Combining literal substitutions with other types is also possible.

<span th:text="'Combined: ' + |Hello ${username}!How are you today?|"></span>

2.2.3 Arithmetic Operations, Comparators and Equality

You can use arithmetic operators in Thymeleaf also.

<div th:with="totalCost=${perPrice} * ${totalCount}">
    <span th:text="|Total Cost: ${totalCost}|"></span>
</div>

<div th:if="${currentProfile} == 'DEV'">
    <span>Wubba Lubba Dub Dub</span>
</div>

You can also try < (>), > (<), >=, ≤, != or their textual aliases gt, lt, ge, le, not, eq, neq/ne.

2.2.4 `th:if`, `th:unless`, `th:switch`, `th:case`

I think there is no need to explain th:if.

<p th:if="${username} neq null">
    <span th:text="|User exists with name ${username}|"></span>
</p>

There is also th:unless which is inverse of th:if.

th:switch / th:case is also the same.

<div th:switch="${currentProfile}">
    <p th:case="'DEV'">Dev profile.</p>
    <p th:case="'PROD'">Prod profile.</p>
</div>

2.2.5 Loops with `th:each`

Arrays and any kinds of objects that implement Iterable, Enumaration, Iterator, Map can be used for iteration.

<ul th:each="post : ${posts}">
    <li th:object="${post}" th:text="|*{title} - *{excerpt}|"></li>
</ul>

2.2.6 Ternary and Elvis Operator

Ternary operator is not an unfamiliar term. So there’s no need to explain.

<div th:text="${username == null} ? 'Anonymous' : ${username}"></div>

Elvis operator is like Ternary operator but it doesn’t have then part. Let’s write the ternary expression above with the Elvis operator.

<div th:text="${username}?: 'Anonymous'"></div>

2.2.7 th:* Attributes

We’ve gone through most of the syntax. You can use th:... syntax for all HTML5 attributes. There are some examples below:

<img th:src="@{/bernard-black.jpg}"/>
<form th:action="@{~/users}" method="post" />
<input type="button" th:value="#{save_button}">
<input type="checkbox" th:checked="${isUserActive}">
<div th:data-index="${index}"></div>

2.2.8 General Attribute Modification

Standard Dialect has th:attr, th:attrappend, th:attrprepend, th:classappend, th:styleappend to modify attributes.

<input type="button" th:attr="value='Click me!'"/>

As you see, th:attr does not offer a new feature. But the others are more useful. I won’t use all of them in this article. Here’s an example:

<div th:classappend="${isMessageNew}? 'notification'" th:text="${message}"></div>

2.2.9 Local Variables

There are two types of local variable definitions in Thymeleaf. First one is th:object. I have gave an example at 2.2.1. But let’s remember it again:

<div th:object="${post}">
    <h3 th:text="*{title}"></h3>
    <p th:text="*{excerpt}"></p>
</div>

In this example, fields of ${post} is accessible only within div tag. That’s why we call it local variable.

Another option is th:with. This option is more flexible relatively. You can declare a variable in a tag and use it with child tags.

<div th:with="featuringPost=${posts[2]}">
    <p th:text="|Post of the week: ${featuringPost.title}|"></p>
</div>

2.2.10 Thymeleaf Comment Blocks

As you know we use  syntax to create a comment block in HTML. It’s the same with Thymeleaf since Thymeleaf treats them in the same way. But there’s another option. You can create parser-level comment blocks that is removed after the template is parsed and won’t be visible to end-users.

<!-- Users can see me! -->

<!--/* I'm invisible! */-->

There are also prototype-only comment blocks and they are very useful with th:block. But it’s much for a crash course. You can see 11.3 and 11.4.

2.2.11 Expression Inlining

So far, we have seen only tag attributes but Standard Dialect provides also expression inlining. We’ve seen different options:

<p> Hello <span th:text="${username}"></span></p>
<p th:text="|Hello ${username}|"> </p>
<p th:text="'Hello ' + ${username}"></p>

All of them are nice for different cases but you can also use:

<p>Hello [[${username}]]</p>

But personally, I don’t find them useful.

2.3 Expression Objects

So far, we have provided some data to Thymeleaf and used them. There are also some objects which are always available. There are many objects and they have more than 100 methods totally and this would make this article really long. So I will show none or one example per object. 2.3.1 and 2.3.2 will be mostly a list of objects. You can find more in the documentation. [1] [2]

2.3.1 Expression Basic Objects

First two objects are base objects and the others are Web context namespace shortcuts.

#ctx

Context object. There are also two synonyms: #vars and #root.

#locale

Gets locale of current request.
```
<p th:text="${#locale}"></p>
```

param

Gets request parameters.

session

Gets session attributes.

application

Gets application/servlet context attributes.

2.3.2 Expression Utility Objects

#execInfo

It provides information about processed template.

#messages

Another option for use externalized variables.
```
<p th:text="${#messages.msg('ext_msg')}"></p>
```

#uris

Let’s you perform URI/URL operations.

#conversions

Another option for double brackets. You can set target class.

#dates

Methods for java.util.Date objects.

<p th:text="${#dates.createNow()}"></p>

#calendars

java.util.Calendar version of #dates.

#numbers

Utilities for number objects.

#string

Utilities for String.

<p th:if="${#strings.equals(currentProfile, 'DEV')}">Dev Profile</p>

#objects

#bools

#arrays

#lists

<p th:if="${#lists.size(draftPosts) == 0}">No drafts.</p>

#sets

#maps

#aggregates

#ids

3. A Few Words

As the title suggests it’s a crash course only. Two documentations which I’ve used is much larger. You can go further by checking them. I’m thinking of writing a few blog posts about Thymeleaf also. If I do so, I will add their links here.

Github Repo: https://github.com/kamer/thymeleaf-crash-course

Custom Javax Annotation Error Handling in Spring

Sun, 02 Feb 2020 01:41:00 +0000

Hello! In this article, I’m gonna cover how to override default exception handler method for MethodArgumentNotValidException which is thrown when Java Bean Validation Annotations are violated.

What is Java Bean Validation?

Java Bean Validation is a specification that is defined in JSR-380. It makes possible defining constraints with annotations, write custom constraints, etc. I will use Hibernate Validator since it is the only certified implementation of Bean Validation 2.0. It’s not a requirement to use with Spring but I’m going to implement it with Spring Boot because of its popularity. I will not explain how to use these annotations however you can find it in one of my articles.

Create a Simple Project and Provide Some Annotations

Create a project with Spring Initializr and select Web and Lombok dependencies. Because web-starter includes Hibernate Validator. Then create a class named User as below.

@Data
public class User {

    @Length(min = 2, max = 30, message = "Name must be between 2-30 characters. ")
    @Pattern(regexp = "^[a-zA-Z]+(([',. -][a-zA-Z ])?[a-zA-Z]*)*$", message = "Name is invalid.")
    private String name;

    @Length(min = 2, max = 30, message = "Surname must be between 2-30 characters.")
    @Pattern(regexp = "^[a-zA-Z]+(([',. -][a-zA-Z ])?[a-zA-Z]*)*$", message = "Surname is invalid.")
    private String surname;

    @Email(message = "Enter a valid email address.")
    private String email;

Using an external message source for error messages is better but I didn’t use it because it would make this article longer.

Then create a RestController and accept User as a @Valid input.

@RestController
@RequestMapping("/api/users")
public class UserRestController {

    @PostMapping
    public ResponseEntity<User> saveUser(@Valid @RequestBody User user) {

	return ResponseEntity.ok(user);
    }
}

Do not forget to use @Valid annotation. Because it makes sure that the annotated parameter is validated.

Run the application and send an example request. (You don’t have to use cURL of course. I sent this request with Postman. You can just copy this and import it as a raw text to Postman.)

curl --location --request POST 'http://localhost:8080/api/users' \
--header 'Content-Type: application/json' \
--data-raw '{
      "name": "Marion",
      "surname": "Cotillard",
      "email": "marion@cotillard.com",
      "birthdate": "1975-09-30"
}'

This request will return 200 as could be expected. Now let’s break some rules:

curl --location --request POST 'http://localhost:8080/api/users' \
--header 'Content-Type: application/json' \
--data-raw '{
      "name": "M",
      "surname": "Cotillard",
      "email": "marion@cotillard.com",
      "birthdate": "1975-09-30"
}'

I just broke @Length rule on name field. This request responded with a long response:

{
  "timestamp": "2020-02-01T21:27:06.935+0000",
  "status": 400,
  "error": "Bad Request",
  "errors": [
    {
      "codes": [
	"Length.user.name",
	"Length.name",
	"Length.java.lang.String",
	"Length"
      ],
      "arguments": [
	{
	  "codes": [
	    "user.name",
	    "name"
	  ],
	  "arguments": null,
	  "defaultMessage": "name",
	  "code": "name"
	},
	30,
	2
      ],
      "defaultMessage": "Name must be between 2-30 characters. ",
      "objectName": "user",
      "field": "name",
      "rejectedValue": "M",
      "bindingFailure": false,
      "code": "Length"
    }
  ],
  "message": "Validation failed for object='user'. Error count: 1",
  "path": "/api/users"
}

This can be a confusing response but it’s possible to create a custom response.

Override Exception Handler

Firstly, create a POJO for the custom response.

@Getter
@Setter
@Builder
@AllArgsConstructor
public class CustomFieldError {

      private String field;

      private String message;

}

You can add extra fields but this is enough for this article. Then create an exception handler method:

@ExceptionHandler(MethodArgumentNotValidException.class)
public final ResponseEntity<Object> handleUserMethodFieldErrors(MethodArgumentNotValidException ex, WebRequest request) {
      // some logic
}

Javax Annotations throws MethodArgumentNotValidException.class so, overrode this exception. In the method, extract field errors and create CustomFieldError objects from them.

final List<FieldError> fieldErrors = ex.getBindingResult().getFieldErrors();

final List<CustomFieldError> customFieldErrors = new ArrayList<>();

for (FieldError fieldError : fieldErrors) {

      final String field = fieldError.getField();

      final String message = fieldError.getDefaultMessage();

      final CustomFieldError customFieldError = CustomFieldError.builder().field(field).message(message).build();

      customFieldErrors.add(customFieldError);

}

You can also get rejectedValue and errorCode. Then create an HTTP response and return.

return ResponseEntity.badRequest().body(customFieldErrors);

Run the project again and send the same request. This will return 400 response with the body below:

[
      {
	      "field": "name",
	      "message": "Name must be between 2-30 characters. "
      }
]

You can customise this response or override similar exception handlers with the same approach.

Github Repo: https://github.com/kamer/custom-javax-annotation-error-handling

Kitap İncelemesi: Docker Deep Dive

Sat, 28 Dec 2019 22:53:19 +0000

Bir süredir Docker hakkındaki bilgimi artırmak ve temel bilgilerimi pekiştirmek için bir kitap okumayı düşünüyordum. Birçok kitap arasında hangisini okuyacağıma karar veremediğim için en kısa yol olan akışına bırakmayı tercih etmiştim. Derken Twitter`da @ozgurozturknet‘in Docker ve Kubernetes için kitap önerdiği twiti gördüm.

Ben de daha önceki araştırmalarımda gördüğüm bu kitaba hemen başladım. Genel olarak akıcı ve okuması keyifli bir kitap olduğunu söyleyebilirim. Bu yüzden çok kısa sürede bitti. Bu kısa incelemenin kitabı okumak konusunda kararsız olanlar için faydalı olacağını düşünüyorum.

Kitabı nereden edinebilirim?

Kitabın fiziksel baskısını Amazon‘dan 55 dolara alabilirsiniz. Kurları düşündüğümüzde bu çok mantıklı gelmiyor. Diğer bir seçenek ise Leanpub‘dan 10 dolar karşılığında dijital formatlarını satın almak. Yazar kitabı sürekli olarak güncel tutacağına ve herhangi bir formatta kitabı satın alanların güncel halinin dijital kopyalarına erişimi olacağına dair garanti veriyor. Eğer ücretsiz olarak ulaşmak isterseniz de libgen’den ulaşabilirsiniz. Fakat bu durumda -en azından şimdilik- kitabın güncel olmayan bir kopyasına ulaşırsınız. (2019 Aralık itibariyle en güncel kopyası 2017 Ekim’e ait.)

Kitap kime hitap ediyor?

Daha kitabın en başında yazdığı üzere Docker’ın nasıl çalıştığını merak etmiyorsanız bu kitapla vakit kaybetmeyin. Çünkü teorik yönü daha ağır basan bir kitap ve pratik için daha iyi seçenekler bulabilirsiniz. Tabii bu kitap da komutları nasıl kullanmanız gerektiğini anlatıyor, gerçek örnekler veriyor ama odak noktası genel olarak Docker’ın iç yapısı. Seviye olarak değerlendirdiğimde ise her seviyeye hitap edeceğini düşünüyorum. Eğer daha önce birkaç Docker komutu bile yazmadıysanız en azından bir container oluşturmanızı tavsiye ederim. Kitabın başlangıcında sizi daha rahat hissettirecektir.

Kitap hangi konuları içeriyor?

Docker’ın geçmişi, Docker Inc., Docker ve VM farkı, OCI gibi konularla The big picture stuff kısmını tamamlıyorsunuz. Sonra daha teknik kısımlar olan Docker Engine, Image, Container, Uygulama Dockerize etme, Swarm Modu, Docker Networking, ve Güvenlik konularıyla da kitabı bitiriyorsunuz. Temelde ihtiyaç duyacağınız birçok konu başlığını akıcı bir dille anlatıyor.

Konuları nasıl bir yöntem ile anlatıyor?

Her bölüme TLDR kısmı ile başlıyor. Bu kısımda adı üstünde TLDR seviyesinde yüzeysel bir bilgi sunuyor. Genel olarak ne anlatacağını özetliyor diyebilirim. Sonra Deep Dive bölümü ile konunun asıl kısmını anlatıyor. Bu kısımda genelde o konunun geçmişinden başlayıp gelişimini anlatıyor. Docker’ın yapısında alınan bazı kararların sebebini açıklaması benim çok hoşuma gitti. Aynı zamanda bu kısımda kitabı okuyan kişinin pratik yapabileceği basit örnekler de veriyor. Deep Dive kısmından sonra o bölümde kullanılan komutları açıkladığı commands kısmı geliyor. Son olarak da summary kısmında bölümün çok kısa bir özetini yapıp diğer bölüme geçiyor.

Son birkaç cümle

Genel olarak kitaptan memnun kaldığımı söyleyebilirim. Docker’la ilgili olarak sadece kendi dokümanlarını okuduğum için karşılaştırma yapabileceğim bir kitap yok ama Docker’a başlangıç yapmak isteyen birine önerebileceğim bir kitap. Eğer maksadınız Docker’ı sadece kullanmak ise bu kitapla vakit kaybetmeden direkt dokümandan faydalanın. Çünkü bu kitap size pratikten çok teorik bilgi aktarmak için yazılmış bir kitap. Ama kullandığınız aracın nasıl çalıştığı hakkında bilgi sahibi olmanın önemini göz ardı etmeyin.

Docker ile PostgreSQL Kurulumu

Sat, 21 Dec 2019 23:07:12 +0000

Merhaba, bu yazıda Docker ile PostgreSQL container‘ı ayağa kaldırmayı ve kullanmayı anlatacağım. Yazı herhangi bir Docker bilgisi gerektirmemektedir. Yalnızca kulak aşinalığı yeterlidir. Komutları tek tek açıklayacağım.

Bilgisayarınızda Docker’ın kurulu olduğunu varsayıyorum. Eğer yüklü değilse bu bağlantıya giderek kurulum yapabilirsiniz.

1. Uygun bir image bulmak

Bu adım zorunlu değildir. Docker’ı giriş seviyesinde bilenler için ekstra bir adımdır.

Kullanmak istediğimiz image‘ı Docker Hub’dan arayacağız. Bunun için terminalden docker search postgresql şeklinde bir arama yapabiliriz. Bu arama aşağıdaki çıktıyı verecektir:

En üstte postgres adıyla yayınlanmış official olarak işaretlenmiş bir image göreceksiniz. Bu bizim işimizi görüyor.

Arama yapmak için diğer bir seçenek ise Docker Hub’dır. Bunun için https://hub.docker.com/ adresine giderek arama yapabilirsiniz.

2. Image’ı indirmek ve container oluşturmak

Bir önceki adımda kullanacağımız image‘ı bulduk. (postgres) Şimdi de image dosyasını indirip container oluşturacağız.

Bunun için docker pull postgres yazın ve indirmenin bitmesini bekleyin. İndirme bittikten sonra kontrol etmek isterseniz docker images veya docker image ls komutlarını kullanabilirsiniz.

Eğer image sorunsuz olarak indiyse aşağıdaki komut ile container oluşturabilirsiniz:

docker run --name <CONTAINER_ADI> -e POSTGRES_PASSWORD=<ROOT_PAROLASI> -d -p 5432:5432 -v <HOST'TA_HERHANGI_BIR_DIZIN>:/var/lib/postgresql/data  postgres

Komutu parça parça inceleyelim.

docker run: Herhangi bir image ismi verdiğinizde o image’ı kullanarak bir container oluşturur ve dilediğiniz komutları çalıştırır.
--name: Container adı vermek için kullanılır.
-e: Ortam değişkeni(environment variable) tanımlamak için kullanılır. Her image’ın kendine ait ortam değişkenleri olur. postgres’in diğer değişkenlerini görmek için bu bağlantıya gidebilirsiniz. Bizim kullandığımız POSTGRES_PASSWORD değişkeni superuser parolasıdır. Eğer POSTGRES_USER değişkenini kullanmazsanız varsayılan superuser olan postgres‘in parolasını belirlemiş olursunuz.
-d: Container‘ı arkaplanda oluşturur ve container ID’sini ekrana yazdırır. (--detach)
-p: Container portlarını açar. Burada postgres’in varsayılan portu olan 5432’yi 5432 portunda açtık. Böylece host olan sistemden erişebileceğiz.
-v: Container‘lar silindiğinde içindeki veriler de silinir. Volume kullanarak container içindeki bir dizini host olan bilgisayardaki bir dizin ile eşleştiriyoruz. Böylece container silindiğinde verileri kaybetmiyoruz. İlk kısım host’taki dizin, ikincisi ise container içinde eşleştirdiğimiz dizin.
postgres: bu da kullanılacak olan image adı.

Yukarıdaki taslağı kullanarak aşağıdaki gibi bir komut çalıştırıyorum:

docker run --name docker_postgres -e POSTGRES_PASSWORD=123456 -d -p 5432:5432 -v $HOME/docker/volumes/postgres:/var/lib/postgresql/data postgres

Komutu çalıştırdığımda -d yazdığım için ekrana yalnızca container id’sini yazacak. Container‘ın çalışıp çalışmadığını görmek için docker container ls veya docker ps yazabilirsiniz.

3. psql’e Erişmek

Çalışan container’ın psql terminaline erişmek için ise aşağıdaki komutu yazıyoruz:

docker exec -it <CONTAINER_ADI> psql -U <KULLANICI_ADI>

Bu komutu da parçalara bölelim:

docker exec: Çalışan bir container içinde komut çalıştırmak için kullanırız.
-it: t ile komut yazabileceğimiz bir terminal istediğimizi (tty), i ile de bu terminalin interaktif olmasını istediğimizi belirtiyoruz. (interactive)
psql -U: Bunun zaten docker ile bir ilgisi yok. Eğer docker run komutunu çalıştırırken POSTGRES_USER ortam değişkeniyle bir kullanıcı adı belirlemediyseniz varsayılan kullanıcı olan postgres‘i girmeniz gerekiyor.

Bundan sonraki aşamalar Docker’dan bağımsız olarak ilerliyor. Psql ile veritabanı oluşturup dilediğiniz client ile bağlanabilirsiniz. Bu yazıyı hazırlarken yalnızca Docker dokümanlarından faydalandım. Komutların referansları aşağıdadır:

Validations is Spring Boot

Mon, 30 Sep 2019 19:27:12 +0000

Hello! In this article, I`m gonna cover validations in a Spring Boot app. The only requirement for you to understand this topic is to be able to create controllers in Spring Boot and of course, be comfortable with Java.

You can find source code for examples here: https://github.com/kamer/validations-in-spring-boot

Table of Contents

Why do we need both client-side and server-side validation?

In web applications, we generally use both client-side and server-side validations for form data or any other data that goes to server-side. Why do we bother with both of them?

Because we use client-side validation to validate and respond quickly. For instance, we have a field that accepts phone number. So, first of all, we should prevent user to type any character other than numbers. Also, we have a pattern that validates phone number. If we control and reject any incorrect input value on the client-side we eliminate the time for this request to go server-side and get rejected. So we can say that client-side validations are mostly used to give user fast feedback and validate syntactical things. (e.g. pattern, length, characters)

But client-side validations can be considered useless since they can be easily manipulated or disabled. Here’s a great representation what it is like to trust any kind of client-side validation.

If we go on with the above image, we should create a validation mechanism that rejects any other number than 911 as input. Here’s where server-side validation comes into play. Briefly, server-side validation is our last chance to reject incorrect inputs properly. Also, we validate constraints that need more logical operations on server-side. For instance, rejecting creation of an employee if the manager of the department is not assigned yet. Enough for introduction, let’s get our hands dirty.

Javax Validation Constraints

javax.validation is the top-level package for Bean Validation API and it has some predefined annotation-based constraints in constraints package for us to use. Here are some examples.

If we want to check a field if it’s null, we use @NotNull annotation.

@NotNull(message = "Name cannot be null.")
private String name;

In the above example name field cannot be null. But it can be empty. If we use @NotBlank name cannot be null and must contain at least non-whitespace one character or if we use @NotEmpty annotation name cannot be null and name.length() > 0. So it can accept a String that has whitespace character.

If we limit any number input we use @Max and @Min annotations.

@Min(value = 3, message = "Experience must be at least 3 years.")
private Integer experienceInYears;

@Positive, @Negative, @PositiveOrZero and @NegativeOrZero annotations do what their name suggests.

@PositiveOrZero(message = "You cannot have negative numbers of children.")
private Integer numberOfChildren;

@Size annotation gives minimum and maximum values for size of anything. (CharSequence, Collection, Map, Array)

@Size(min = 2, max = 35, message = "Surname must be 2-35 characters long.")
private String surname;

@Past, @Future, @PastOrPresent, @FutureOrPresent annotations validate date types according to their name.

@Past(message = "Date input is invalid for a birth date.")
private LocalDate dateOfBirth;

You can validate any regex pattern with @Pattern annotation.

@Pattern(regexp = "^4[0-9]{12}(?:[0-9]{3})?$", message = "Only Visa cards are accepted.")
private String cardNumber;

No need to explain @Mail annotation.

@Email(message = "Enter a valid email address.")
private String email;

I explained the most important ones above. If you want to see the others you can find them here.

I created a dummy example to try these constraints and show validation messages on form inputs with Thymeleaf. We should annotate controller input with @Valid to activate these constraints.

@PostMapping("/javax-constraints")
String postJavaxConstraints(@Valid JavaxValidationConstraints javaxValidationConstraints, BindingResult bindingResult) {
   ...
   ...
   ...
}

Then show error messages on Thymeleaf.

Creating Your Own Validation Annotations

If you have followed previous chapter well you should’ve seen that you achieve almost anything with Javax Validation Constraints. But sometimes defining your own annotations can seem a much better option though.

Here’s one example. We want to validate creditCard field with @Pattern.

@NotEmpty(message = "You must enter a credit card number.")
@Pattern(regexp = "^(?:4[0-9]{12}(?:[0-9]{3})?|[25][1-7]"
		+ "[0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}"
		+ "|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])"
		+ "[0-9]{11}|(?:2131|1800|35\\d{3})\\d{11})$",
	    message = "Invalid card number.")
private String creditCard;

Do you see any problem here? It seems too ugly considering we will have at least 5 more fields with at least 2 validation annotations and so on. In this type of situation we can choose defining our own annotation.

First of all create an annotation as below.

@Documented
@Constraint(validatedBy = CreditCardValidator.class)
@Target({ ElementType.FIELD })
@Retention(RetentionPolicy.RUNTIME)
public @interface CreditCard {

    String message() default "Invalid card number";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
 }

We want our annotation to serve at runtime, to be used with field types and to be validated by CreditCardValidator class.

So here’s our validator class.

We implement ConstraintValidator<[AnnotationsName], [TargetType]> and enforcedly override initialize() and isValid() methods. initialize method is guaranteed to be run before any use of this validation and isValid method is where we reject or accept any value.

public class CreditCardValidator implements ConstraintValidator<CreditCard, String> {

      private static final String CREDIT_CARD_REGEX = "^(?:4[0-9]{12}(?:[0-9]{3})?|[25][1-7][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\\d{3})\\d{11})$";

      private static final Pattern CREDIT_CARD_PATTERN = Pattern.compile(CREDIT_CARD_REGEX);

      @Override
      public void initialize(CreditCard constraintAnnotation) {

      }

      @Override
      public boolean isValid(String creditCardNumber, ConstraintValidatorContext context) {

	      Matcher matcher = CREDIT_CARD_PATTERN.matcher(creditCardNumber);

	      return matcher.matches();

      }
}

Our annotation is ready. Let’s use them like the ones above.

@PostMapping("/custom-constraint-annotation")
      String postCustomConstraint(@Valid CustomConstraintAnnotation customConstraintAnnotation, BindingResult bindingResult) {

	      if(bindingResult.hasErrors()){

		      return "custom-constraint-annotation";
	      }
	...
	...
	...
    }
}

All validation errors are saved in BindingResult object and we can show error messages with Thymeleaf.

<form role="form" th:object="${customConstraintAnnotation}" th:action="@{/custom-constraint-annotation}" th:method="post">

    <div style="color: red;" th:if="${#fields.hasErrors('*')}">
	<p><strong>Errors</strong></p>
	<ul>
	    <li th:each="err : ${#fields.errors('*')}" th:text="${err}"></li>
	</ul>
    </div>

    <label>Credit Card Number</label>
    <br>
    <input type="text" id="creditCard" name="creditCard" th:field="*{creditCard}">
    <br>
    <input type="submit">
</form>

Combining Multiple Annotations

Another way of implementing good validations is combining multiple validation annotations. Hibernate documentation calls it Constraint composition. It’s quite simple. First of all create an annotation type and fill as below.

@NotEmpty
@Size(min = 8)
@Pattern(regexp = "\"^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)[a-zA-Z\\d]$\"")
@Target({ METHOD, FIELD, ANNOTATION_TYPE })
@Retention(RUNTIME)
@Constraint(validatedBy = {})
@Documented
public @interface CombinedPasswordConstraint {

      String message() default "Invalid password.";

      Class<?>[] groups() default {};

      Class<? extends Payload>[] payload() default {};
}

You can add different messages for each annotation. Then use it like the other constraints.

Creating Custom Validator Class

We’ve been through constraints so far. It’s time to create a more complicated validation with a custom validator class. In previous examples we’ve validated syntactical things. But generally we need more complicated things that possibly need a database query.

I’m repeating prior example. You have created a department in your imaginary app. Then you try to add a new employee to this department. But you want to add a constraint that requires assigning a manager before assigning an employee. So you should add a validator that checks either this department has a manager or not. This is possible with custom validator. But you can also validate simple things like regex patterns.

Let’s create one.

I’m gonna show you a simplified example. First of all, create a dummy class and fill it as below.

public class CustomValidationEntity {

      private String email;

      private Long departmentId;

      public Boolean existManagerByDepartmentId(Long departmentId) {

	      return false;
      }

      public Boolean existEmployeeWithMail(String email) {

	      return true;
      }

}

It will always say ‘department has no manager’ and ‘this email already exist’ whatever we enter.

Then create validator class as below. I’m gonna explain details.

@Component
public class CustomValidator implements Validator {

      @Override
      public boolean supports(Class<?> clazz) {
	      return CustomValidationEntity.class.isAssignableFrom(clazz);
      }

      @Override
      public void validate(Object target, Errors errors) {

	      CustomValidationEntity customValidationEntity = (CustomValidationEntity) target;

	      if (customValidationEntity.existEmployeeWithMail(customValidationEntity.getEmail())) {

		      errors.rejectValue("email", null, "Employee with this email is already exists.");
	      }

	      if (!customValidationEntity.existManagerByDepartmentId(customValidationEntity.getDepartmentId())) {

		      errors.reject(null, "Department does not have a manager.");
	      }

      }
}

This Validator interface that we extend is org.springframework.validation.Validator;. Not javax… one. This interface gives us two methods. supports() method controls if the target object is what we intended to validate and validate() method is where we control and reject things. You can reject the whole object and add a global error message with reject() or reject a single value and add an error message for this value with rejectValue(). Then you should annotate this class with @Component.

Let’s use our validator. But we will do something different than using constraints. After annotating object parameter in the controller with @Valid, we will add an InitBinder method in that controller.

@InitBinder
private void bindValidator(WebDataBinder webDataBinder) {
    webDataBinder.addValidators(customValidator);
}

This @InitBinder annotated method will initialize WebDataBinder. Since WebDataBinder prepares objects that come from requests for controllers, it can validate before the request reaches controller. That’s it. Let’s try our example.

Spring Boot Uygulamasında Üye Kaydı ve Girişi

Fri, 27 Sep 2019 19:27:12 +0000

Güncelleme 02.05.2020: csrf().disabled() konfigürasyonu ve CustomAuthenticationProvider sınıfı kaldırıldı. Ayrıca Optional kullanımını değiştirdim ve orElseThrow() metodunu kullandım. Değerli yorumları için @gokcensedat ve @utkuozdemir‘e teşekkür ederim.

Merhaba, bu yazımda Spring Boot uygulamasında kullanıcı kaydı, onay maili gönderme ve kullanıcı girişi işlemlerinin nasıl yapılacağını anlatacağım. Ana konudan sapmamak için exception handling kısımlarından bahsetmeyeceğim. Spring Boot hakkında bilgi sahibi olmanız, tercihen bir IDE kullanmanız gerekmektedir.

Doğrudan kaynak kodları incelemek için: https://github.com/kamer/spring-boot-user-registration

└── main
    ├── java
    │   └── com
    │       └── kamer
    │           └── springbootuserregistration
    │               ├── config
    │               │   ├── CustomAuthenticationProvider.java
    │               │   ├── WebConfig.java
    │               │   └── WebSecurityConfig.java
    │               ├── entity
    │               │   ├── User.java
    │               │   └── UserRole.java
    │               ├── SpringBootUserRegistrationApplication.java
    │               └── user
    │                   ├── ConfirmationToken.java
    │                   ├── ConfirmationTokenRepository.java
    │                   ├── ConfirmationTokenService.java
    │                   ├── EmailSenderService.java
    │                   ├── UserController.java
    │                   ├── UserRepository.java
    │                   └── UserService.java
    └── resources
	├── application.yml
	├── static
	└── templates
	    ├── sign-in.html
	    └── sign-up.html

Spring Initialzr ile Projenin Oluşturulması

https://start.spring.io/ adresine giderek veya kullandığınız IDE’nin ilgili plugin’lerini kullanarak bir proje oluşturun. Projede Spring Web, Lombok, Thymeleaf, Spring Security, Java Mail Sender, H2 ve Spring Data JPA dependency’lerini seçin. Tercihen farklı bir veritabanı da kullanabilirsiniz.

User Entity’sinin Oluşturulması

entity adında bir package oluşturun ve içinde UserRole adında bir enum yaratın. Kullanıcı rollerini tutacağımız bu enumda ADMIN ve USER adında iki değer olacak.

enum UserRole {

    ADMIN, USER
}

Sonra User adında bir class yaratın. Bu class UserDetails interface’ini implement etmeli. UserDetails interface’i temel kullanıcı bilgilerinin metotlarını barındıran bir interface. Örnek bir kullanımını görmek için org.springframework.security.core.userdetails.User sınıfına bakabilirsiniz. Hatta doğrudan bu sınıfı extend edip eklemek istediğiniz değişkenleri ekleyebilirsiniz. Ben extend etmeden sıfırdan bir class oluşturacağım. Birkaç değişken oluşturup UserDetails’dan gelen metotların bodylerini dolduracağız.

@Setter
@Builder
@EqualsAndHashCode
@NoArgsConstructor
@AllArgsConstructor
@Entity(name = "Users")
public class User implements UserDetails {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    private String surname;

    private String email;

    private String password;

    @Builder.Default
    private UserRole userRole = UserRole.USER;

    @Builder.Default
    private Boolean locked = false;

    @Builder.Default
    private Boolean enabled = false;

    @Override
    public Collection&lt;? extends GrantedAuthority&gt; getAuthorities() {

	final SimpleGrantedAuthority simpleGrantedAuthority = new SimpleGrantedAuthority(userRole.name());
	return Collections.singletonList(simpleGrantedAuthority);
    }

    @Override
    public String getPassword() {
	return password;
    }

    @Override
    public String getUsername() {
	return email;
    }

    @Override
    public boolean isAccountNonExpired() {
	return true;
    }

    @Override
    public boolean isAccountNonLocked() {
	return !locked;
    }

    @Override
    public boolean isCredentialsNonExpired() {
	return true;
    }

    @Override
    public boolean isEnabled() {
	return enabled;
    }
}

expired değişkenini kullanmayacağım için isAccountNonExpired ve isCredentialsNonExpired metotlarından true döndürdüm. Username yerine email kullanacağım için de getUsername metodundan email döndürdüm. Diğerlerini metot isimlerinden çıkarabilirsiniz.

UserService’in Oluşturulması

Kullanıcı kaydı işlemlerini yapacağımız UserService classı için user adında bir package oluşturacağız. Bu class da UserDetailsService interfaceini implement edecek. Bu interfaceten loadByUsername adında bir metot alacağız. email kullanacağımız için bu sınıf da adı loadByUsername olsa da mail parametresi alıp ona göre kullanıcı döndürecek.

Tabii veritabanından kullanıcı çekmek için önce repository’e ihtiyacımız var. Hemen aynı sınıf içinde UserRepository interfacei oluşturuyoruz ve içinde findByEmail metot imzasını oluşturuyoruz.

interface UserRepository extends CrudRepository<User, Long> {

    Optional<User> findByEmail(String email);
}

Şimdi UserService’e geri dönüp loadByUsername metodunun içini doldurabiliriz.

@Override
public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {

    final Optional<User> optionalUser = userRepository.findByEmail(email);

    if (optionalUser.isPresent()) {
	return optionalUser.get();
    }
    else {
	throw new UsernameNotFoundException(MessageFormat.format("User with email {0} cannot be found.", email));
    }
}

ConfirmationToken Classının Oluşturulması

Her kullanıcı kaydolduğunda bir token oluşturacağız ve göndereceğimiz mailde bu token ile eşsiz bir link oluşturacağız. user packageı içinde ConfirmationToken adında bir class yaratıyoruz ve aşağıdaki şekilde dolduruyoruz.

@Entity
@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
class ConfirmationToken {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String confirmationToken;

    private LocalDate createdDate;

    @OneToOne(targetEntity = User.class, fetch = FetchType.EAGER)
    @JoinColumn(nullable = false, name = "user_id")
    private User user;

    ConfirmationToken(User user) {
	this.user = user;
	this.createdDate = LocalDate.now();
	this.confirmationToken = UUID.randomUUID().toString();
    }
}

Her kullanıcıya bir token vereceğimiz için OneToOne ilişki kuruyoruz ve tokenların bir geçerlilik süresi olacağı için createdDate değişkeni tutuyoruz.

Örnek Kullanıcı Kaydı Senaryosuna Göre Metotların Yazılması

Servisleri ve tüm metotları en baştan yazmak yerine aşama aşama gitmeyi daha doğru buluyorum. Böylece gerçek bir geliştirme akışına daha yakın bir yazı olacak.

Kullanıcı kaydında önce kullanıcı bilgilerini alacağız. Sonra BCryptPasswordEncoder ile parolayı encode edeceğiz ve kullanıcıyı enabled=false(default) olacak şekilde kaydedeceğiz. Sonra bir ConfirmationToken oluşuturup bu token’ı kullanıcı ile ilişkilendireceğiz. Token ile eşsiz bir link oluşturup kullanıcıya mail yoluyla göndereceğiz. Kullanıcı bu linke tıkladığında ise ilgili kullanıcının enabled alanı true olacak ve token silinecek.

signUpUser metodunu oluşturmadan önce ConfirmationTokenRepository ve ConfirmationTokenService oluşturup yeni token kaydetmek için bir metot oluşturacağız.

@Repository
interface ConfirmationTokenRepository extends CrudRepository<ConfirmationToken, Long> {

}

@Service
@AllArgsConstructor
class ConfirmationTokenService {

    private final ConfirmationTokenRepository confirmationTokenRepository;

    void saveConfirmationToken(ConfirmationToken confirmationToken) {

	confirmationTokenRepository.save(confirmationToken);
    }

Şimdi UserServicee gidip signUpUser metodunu yazalım.

void signUpUser(User user) {

    final String encryptedPassword = bCryptPasswordEncoder.encode(user.getPassword());

    user.setPassword(encryptedPassword);

    final User createdUser = userRepository.save(user);

    final ConfirmationToken confirmationToken = new ConfirmationToken(user);

    confirmationTokenService.saveConfirmationToken(confirmationToken);

}

Mail Confirmation Metotlarının Yazılması

Senaryoda kullanıcı, kendisine gelen maile tıkladığında çalışacak olan metodu yazalım. Önce link ile maili onayladıktan sonra token‘ı silecek olan metodu yazalım.

void deleteConfirmationToken(Long id){

    confirmationTokenRepository.deleteById(id);
}

Şimdi de maili confirm edecek olan metodu yazalım.

void confirmUser(ConfirmationToken confirmationToken) {

  final User user = confirmationToken.getUser();

  user.setEnabled(true);

  userRepository.save(user);

  confirmationTokenService.deleteConfirmationToken(confirmationToken.getId());

}

Spring Mail Ayarları

Ben Gmail için örnek bir yml dosyasını aşağıda paylaşıyorum. Eğer 2-factor kullanıyorsanız uygulama için özel bir parola oluşturmanız gerekiyor. (https://support.google.com/mail/answer/185833?hl=en) yml yerine application.properties de kullanabilirsiniz.

spring:
  mail:
    host: smtp.gmail.com
    port: 587
    username: <MAIL ADRESI>
    password: <PAROLA>
    properties:
      mail:
	smtp:
	  auth: true
	  starttls:
	    enable: true
	  connectiontimeout: 5000
	  timeout: 3000
	  writetimeout: 5000

EmailService’in ve Mail Gönderen Metodun Yazılması

user package‘ı içinde EmailSenderService adında bir class oluşturun ve aşağıdaki şekilde doldurun.

@Service
@AllArgsConstructor
public class EmailSenderService {

    private JavaMailSender javaMailSender;

    @Async
    public void sendEmail(SimpleMailMessage email) {
	javaMailSender.send(email);
    }
}

Şimdi de UserService içinde mail gönderen metodu yazalım.

void sendConfirmationMail(String userMail, String token) {

    final SimpleMailMessage mailMessage = new SimpleMailMessage();
    mailMessage.setTo(userMail);
    mailMessage.setSubject("Mail Confirmation Link!");
    mailMessage.setFrom("<MAIL>");
    mailMessage.setText(
	    "Thank you for registering. Please click on the below link to activate your account." + "http://localhost:8080/sign-up/confirm?token="
		    + token);

    emailSenderService.sendEmail(mailMessage);
}

WebSecurityConfig ve WebConfig Class’ı ile Security Konfigürasyonunun Yapılması

@Configuration
@AllArgsConstructor
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

      private final UserService userService;

      private final BCryptPasswordEncoder bCryptPasswordEncoder;

      @Override
      protected void configure(HttpSecurity http) throws Exception {

	      http
			      .authorizeRequests()
			      .antMatchers("/sign-up/**", "/sign-in/**")
			      .permitAll()
			      .anyRequest()
			      .authenticated()
			      .and()
			      .formLogin()
			      .loginPage("/sign-in")
			      .permitAll();
      }

      @Autowired
      public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
	      auth.userDetailsService(userService)
			      .passwordEncoder(bCryptPasswordEncoder);
      }

}

@Configuration
public class WebConfig {

      @Bean
      public BCryptPasswordEncoder bCryptPasswordEncoder() {

	      return new BCryptPasswordEncoder();
      }
}

Burada hangi sayfaların authentication olmadan kullanılabileceğini, giriş işlemini hangi path‘in handle edeceğini seçiyoruz.

Controller’ların Yazılması ve Sayfaların Oluşturulması

@Controller
@AllArgsConstructor
public class UserController {

    private final UserService userService;

    private final ConfirmationTokenService confirmationTokenService;

    @GetMapping("/sign-in")
    String signIn() {

	return "sign-in";
    }

    @GetMapping("/sign-up")
    String signUp() {

	return "sign-up";
    }

    @PostMapping("/sign-up")
    String signUp(User user) {

	userService.signUpUser(user);

	return "redirect:/sign-in";
    }

    @GetMapping("/confirm")
    String confirmMail(@RequestParam("token") String token) {

	Optional<ConfirmationToken> optionalConfirmationToken = confirmationTokenService.findConfirmationTokenByToken(token);

	optionalConfirmationToken.ifPresent(userService::confirmUser);

	return "/sign-in";
    }

}

Şimdi de controller‘da yönlendirdiğimiz sayfaları hazırlayalım.

Thymeleaf ile Sayfaların Oluşturulması

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="en">
<head>
    <title>Spring Boot User Authentication</title>
</head>
<body>
<form role="form" th:action="@{/sign-in}" th:method="post">
    <lable>Username</lable>
    <input type="text" id="username" name="username">

    <lable>Password</lable>
    <input type="password" id="password" name="password">

    <input type="submit">
</form>
</body>
</html>

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" lang="en">
<head>
    <title>Spring Boot User Authentication</title>
</head>
<body>
<form role="form" th:action="@{/sign-up}" th:method="post" th:object="${user}">
    <lable>Name</lable>
    <input type="text" id="name" name="name" th:field="*{name}">

    <lable>Surname</lable>
    <input type="text" id="surname" name="surname" th:field="*{surname}">

    <lable>Email</lable>
    <input type="text" id="email" name="email" th:field="*{email}">

    <lable>Password</lable>
    <input type="password" id="password" name="password" th:field="*{password}">

    <input type="submit">
</form>
</body>
</html>

Buraya kadar eksiksiz takip ettiyseniz http://localhost:8080/sign-up adresinden kullanıcı kaydı yapabilirsiniz. Tabii ki bu haliyle yetersiz bir proje. Çünkü exception handling kısımlarını eklemedim. Aynı zamanda token‘ların geçerliliğini kontrol etme gibi şeyleri de kontrol etmedim. Bunlar basit işlemler olduğu için yalnızca üye kaydı ve girişi yapacağınız kısımdan bahsettim.

CAP Teorisi ve Blokzincir

Sat, 06 Jul 2019 19:27:12 +0000

Dağıtık sistemler hakkında bazı tezler öne süren CAP teorisi, 2000 yılında Eric Brewer tarafından ortaya atılmış ve 2002 yılında Seth Gilbert ve Nancy Lynch tarafından ispatı yayınlanmıştır. O zamandan bu yana da birçok dağıtık sistemin tasarımını etkilemiştir. Peki CAP teorisi blockzincir teknolojisine dair düşüncelerimizi ne yönde etkileyebilir? Bu sorunun cevabını verebilmek için öncelikle CAP teorisini inceleyelim.

CAP Teorisi

Teori, veri paylaşımının yapıldığı dağıtık sistemlerin tasarımında bazı “trade-off”lara dikkat çeker. Bu sistemlerde aşağıda bahsedeceğim üç özellikten en fazla iki tanesinin garanti edilebileceğini öne sürer. Baş harfleriyle teoriye adını veren özellikler şunlardır:

Consistency(Tutarlılık): Ağda bulunan her düğümün(node) verilerin en güncel halini barındırmasıdır. Yani her düğümün aynı veriye sahip olmasıdır. Gilbert ve Lynch’in consistency yerine “atomic” kelimesini kullandıkları bu özellik hakkında belirlediği önemli bir ayrıntıyı gözden kaçırmamak lazım. Bir sistem ya “consistent”tır, ya da değildir. Yani yarım tutarlı ve büyük oranda tutarlı gibi ifadeler bu tanımın kapsamına girmez.

Availability(Ulaşılabilirlik): Tüm aktif düğümler kendilerine gelen bütün isteklere belli bir zaman içinde cevap vermek zorundadır. Burada tek gereklilik bütün isteklere cevap verilmesi. Verinin tutarlı olup olmaması bu özelliğin dışındadır. Diğer yandan ulaşılabilir bir sistemde mevcut düğüm cevap veremiyorsa da ağdaki işlemler devam eder.

Partition tolerance(Bölünme toleransı): Ağ problemlerinde sistemin devamlılığını sürdürmesidir. Ağ hatalarından dolayı sistemdeki düğümler bölünebilir. Bu gibi bölünmelerde A’nın veya C’nin sürdürülmesidir. Yani sistemin hata toleransı sağlamasıdır.

Yukarıdaki üç kavramın üçü de aynı anda sağlanamayacağından teori üç alt kategoriye ayrılıyor. Yani ikişer olarak bu kavramların başarıldığı kombinasyonlara.

1. CA

Teoriyi blokzincir ışığında değerlendirdiğimiz için bu ihtimal üzerine kafa yormaya gerek yok. Partition tolerance zaten blokzincirlerin karakteristik bir özelliği. Tek bir düğümü olan merkezi veritabanları bu kategoriye girer.

2. CP

Bu tip bir ağda partition durumunda tolerans sağlanır fakat verilerin tüm düğümler arasında güncel olup olmadığı sorusu bir zafiyete sebep olur. Çünkü bölünen düğümlerle iletişim kuramayız. Bu durumunda bir trade-off yapmamız gerekiyor. C’yi seçtiğimizde,verilerin güncel olmaması ihtimalinden dolayı hata mesajı göndererek cevap veririz.

3. AP

CP sistemlerdeki P için bir değişme yoktur. Fakat C ve A arasındaki seçimimizde tercih hakkımızı A’dan yana kullanırsak AP sisteme sahip oluruz. AP sistemde istemcilerden gelen tüm isteklere cevap verilir. Fakat partition durumunda bu verilerin en güncel olup olmadığı doğrulanmaz.

Blokzincir Ağları Hangi Özellikten Feragat Ediyor Olabilir?

Bu konuyu düşünürken hepimizin aşina olduğu Bitcoin örneği üzerinden ilerleyeceğim. Teoriye göre dağıtık bir sistemde bir özellikten feragat etmek zorundayız. Peki bitcoin hangisinden feragat ediyor? İhtimallerle beraber değerlendirelim.

Partition Tolerance: Önce bunu aradan çıkaralım. Herhangi bir blokzincirde partition tolerance’tan feragat edemeyiz. Zaten blokzincir teknolojisinin sağladığı en önemli şeylerden biri bu toleranstır.

Availability: Eğer bitcoinde availability’den feragat edilirse bir düğümde bağlantı problemi yaşandığında bitcoin transferleri duracaktır. Çünkü ulaşılabilir bir ağda mevcut düğümde problem yaşandığında da ağ işlevine devam eder.

Consistency: Tutarlılıktan feragat edersek de yine ciddi bir zafiyetimiz olur. Tutarlı olmayan hayali bir bitcoin ağında işlemlerin gerçekleştiği garanti edilemez. İşlemi başlatabiliriz fakat bu işlemin, yeterli sayıda düğüme ulaşmadığı için, gerçekleşmeme şansı olur.

Birer birer incelediğimizde üç özelliğin de eksikliği ciddi zafiyetler yaratacak gibi duruyor. Öyleyse Bitcoin, CAP teorisini çürütüyor mu?

Kısa cevap, hayır çürütmüyor. Uzun cevap için konudan sapmadan CAP teorisini biraz daha irdelememiz gerekiyor. Öncelikle şunu düşünelim, bir sistemin tutarlı olması için ne gerekir? Daha önce de bahsettiğimiz gibi tüm düğümler verilerin en güncel halini barındırmalı. Bunu sağlamak için de bölünme durumunda ağ bunu tespit edebilmeli. Her dağıtık sistem bunu sağlamak için farklı stratejiler kullanır. Bu stratejilerden biri de consensus(fikir birliği) algoritmalarıdır. Yani çoğunluğun fikir birliğine varması. Bitcoinde bölünme tespiti ve tutarlılık için fikir birliği algoritmaları ne kadar uygulanabilir? Daha açık bir ifadeyle şu an, şu saniye bitcoinde fikir birliğine varılması için kaç düğümün aynı fikirde olması gerekiyor? Bu sorunun cevabı çok değişken. Çünkü public bir ağ ve ağa katılmak, ağdan ayrılmak gibi işlemler çok kolay. Yani çoğunluk hesaplamak çok zor bir işlem. Hadi bunu örneklendirelim. Bir felaket sonucu Amerika kıtası ve dünyanın geri kalanı arasında internet erişiminin koptuğunu düşünün. Bu durumda bitcoin, tutarlılığını nasıl sağlayacak? Bitcoinin çalışma prensibini düşündüğümüzde böyle bir durumda iki zincir olacağını ve bitcoinin eskisi gibi çalışmaya devam edeceğini tahmin edebiliriz. Çünkü bölünme toleransı sayesinde sistem işlevselliğini devam ettiriyor. Ama tutarsız olarak. Çünkü iki farklı zincirde gerekli işlem gücü sağlandığında farklı işlemler devam edecek.

Bu durumda bitcoinin consistency’den, yani tutarlılıktan feragat ettiğini söyleyebiliriz. Yazının başından bu yana tutarlılık hakkında söylediklerim bitcoin için de geçerlidir. Bitcoinde bir işlem başlattığımızda bunun gerçekleşmeme olasılığı mevcuttur. Fakat elbette bu olasılık yukarıda bahsettiğim gibi ihtimali düşük senaryolar dahilinde gerçekleşir. Bitcoin tarihindeki forklara bakarsanız consistency problemlerinin zaman zaman yaşandığını ama yaşanan geçici problemlerin düzeltildiğini görebilirsiniz.

Yararlandığım Kaynaklar

NativeScript-Vue ile Mobil Uygulama Geliştirme

Sun, 02 Jun 2019 14:27:02 +0000

Bu yazı 2 Haziran 2019 tarihinde yazılmıştır. Geçen sürede birçok şey değişmiş olabilir. Yazıya başlamadan önce bu durumu göz önünde bulundurmanızı tavsiye ederim.

Bir süredir VueJS kullanarak mobil uygulama geliştirme konusunda bir araştırma yapmayı düşünüyordum. Araştırmalarım sonucu zaten çok fazla seçeneğim olmadığını farkettim ve NativeScript’i denemeye karar verdim. Henüz React Native ile karşılaştırılabilecek seviyede değil. Fakat aktif bir topluluğa sahip ve bu yüzden ileride adını daha çok duyacağımızı düşünüyorum. Öncelikle kısaca nativescript’in ne olduğundan bahsedeyim.

Nativescript, Angular, VueJS, TypeScript, or JavaScript kullanarak IOS ve Android uygulama geliştirme imkanı sunan açık kaynak kodlu bir framework. Eğer VueJS ile kod yazmayı seviyorsanız NativeScript-vue ile uygulama geliştirmek sizin için keyifli bir deneyim olabilir. Eğer çok profesyonel bir uygulamaya ihtiyacınız yoksa ve yeni bir dil/framework öğrenmenize engel bir şeyler varsa NativeScript-Vue işinizi görecektir. İncelediğim kadarıyla güzel bir dokümanları var ve Slack üzerinde faaliyet gösteren aktif bir toplulukları var.

Bu yazıda basit bir uygulama geliştirerek NativeScript’in nasıl çalıştığını göreceğiz. Pratik olması açısından NativeScript Playground ortamını kullanacağız. Bu ortam, doğrudan tarayıcı üzerinde NativeScript uygulamaları geliştirmenize imkan tanıdığı için SDK kurmak gibi şeyler ile uğraşmanıza gerek yok.

1. Çalışma Ortamımızı Hazırlıyoruz

Öncelikle https://play.nativescript.org linkine gidin ve üye olun. Bu zorunlu değil fakat projelerinizin bulut üzerinde bulunmasına imkan tanıdığı için tavsiye ederim. İkinci olarak IOS veya Android cihazınıza NativeScript Playground ve NativeScript Preview uygulamalarını yükleyin. Bunlar da kodunuzun canlı önizlemesini görmeniz için gerekiyor. Linkleri aşağıda bulabilirsiniz.

2. NativeScript Playground’ı Tanıyalım

Playground’ı ilk açtığınızda sizi bu ekran karşılayacak. Gördüğünüz gibi sol üstte Project Explorer var. Yanındaki +’ya tıklayarak npm paketleri, klasörler, dosyalar ekleyebilirsiniz. Sol altta Components sekmesi altında NativeScript bileşenleri bulunmakta. Doğrudan kod yazarak geliştirme yapabileceğiniz gibi buradan çek-bırak ile de çalışabilirsiniz. Editörün masaüstü kod editörlerinde olduğu gibi kod tamamlama gibi özellikleri var. Sağ üstte preview butonuyla da uygulamanızı telefonunuz üzerinden test edebilirsiniz.

3. Projemizin Template’ini Hazırlayalım

Projemiz deneysel bir şey olacağı için fazla ayrıntıya girmeyeceğim. Breaking Bad dizisine ait repliklerin rastgele verildiği bir Rest Api’yi kullanacağımız bir proje olacak. Öncelikle taslak olarak verilen kodda Page etiketi arasındaki kodları silelim. Sonra Page etiketine ActionBar istemediğimize dair bir attribute ekleyelim.

<Page class="page" actionBarHidden="true"> </Page>

Sonra sol altta componentlerin olduğu kısımdan çek-bırak yaparak veya doğrudan kod ile StackLayout ekliyoruz. Layout’a attribute olarak ise dikey hizalama yapmak için orientetion attribute’u ekliyoruz.

<StackLayout orientation="vertical" > </StackLayout>

İçine ise iki tane label ekleyelim. Biri repliğin bulunucağı, diğeri ise repliği söyleyen kişinin adının bulunacağı bileşen. Taşma durumunda yazının bir satır aşağı kayabilmesi için textWrap atttibute’unu true yapalım ve label içeriklerini VueJS ile bind edelim.

<Label id="quote" textWrap="true" :text="quote" /> <Label id="author" textWrap="true" :text="author" />

4. API İşlemleri

Şimdi Script’e gelip data içinde quote ve author değişkenlerini tanımlayalım. İlk değerleri boş olsun. Sonra methods kısmında fetchQuote adında bir metot tanımlayalım. Bu metot içinde API’ye bağlanıp sözü çekeceğiz. Bunun için Script içinde bir import satırı ekleyeceğiz.

import * as http from "http";

Bunu ekledikten sonra metot içine gelip aşağıdaki kodu ekleyin.

http.getJSON("https://breaking-bad-quotes.herokuapp.com/v1/quotes")
.then( res => {
  this.quote = res[0].quote
  this.author = res[0].author;
},
error( error => {
  console.log(error);
}

Burada API’den istek atıp gelen JSON cevabı değişkenlerimize veriyoruz. Bir hata olması durumunda ise konsola yazdırmasını istedik. Gerçek bir uygulama için yeterli bir exception handling yöntemi değil elbette fakat şimdilik bu yeterli.

Şimdi de uygulamayı her açtığımızda otomatik olarak bir replik çekmesi için Script kısmında created() açıyoruz ve içine this.fetchQuote(); yazıyoruz. Şimdiye kadar geldiğimiz aşamayı görmek için sağ üstte Preview butonuna basın ve çıkan QR kodunu Playground uygulamasına okutun.

5. Görsellik ve Event Ekleyelim

Eğer şimdiye kadar doğru takip ettiyseniz yukarıdaki gibi bir sonuç elde edeceksiniz. Bundan sonra her Ctrl+S yaptığınızda bu uygulama güncellenecek.

Temel fonksiyonumuzu yerine getirdiğimize göre şimdi de biraz görsellik katalım. İlk olarak sol üstte Project explorer’ın olduğu kısımda +’ya basıp assets adında bir klasör ekleyelim ve içine şu linkteki resmi yükleyin. Sonra Style kısmına aşağıdaki kodu ekleyin.

#quote {
font-size: 40px;
text-align: right;
margin-top: 30%;
font-weight: bold;
margin-right: 10px;
color: white;
}

#author {
text-align: right;
font-size: 25px;
margin-top: 10%;
margin-right: 3px;
color: white;
}

.page {
background-image: url('~/assets/breaking-bad1.jpg');
background-position: center;
background-size: cover;
}

Kaydettiğinizde aşağıdaki gibi bir şey çıkması lazım.

Uygulamamıza son bir özellik daha ekleyelim. Ekrana her tıkladığımızda yeni replik getirsin. Bunun için event’leri kullanacağız.

Page elementine gelin ve @tap="fetchQuote" yazın. Ekrana dokunduğunuzda o metotu çağıracaktır.

Eğer şimdiye kadar yazıyı doğru takip ettiyseniz aşağıdaki gibi bir sonuç elde etmeniz gerekiyor.

Yapacaklarımız bu kadar. Umarım NativeScript-Vue’yu sevmişsinizdir. Daha fazlasını öğrenmek için ilk tavsiyem NativeScript Playground’da sağ tarafta bulunan iki dersi takip etmeniz. İki örnek ders var. Sonra gayet güzel bir örnek olan market listesi uygulamasını inceleyin. En iyi kaynak ise bence kendi dokümanları.

Projeye ait kodlar için: https://github.com/kamer/nativescipt-vue-breakingbad-replikleri

Arch Linux’da Wi-fi’ye Nasıl Bağlanılır?

Sun, 02 Jun 2019 14:19:51 +0000

Merhabalar. Dün uzun zamandır yüklemeyi düşündüğüm Arch Linux’a geçtim. Her ne kadar rolling-release bir dağıtım olduğu için zaman zaman stabiliteden ödün verdiğine dair eleştirilerin hedefi olsa da okuduğum kadarıyla sevdiğim ve merak ettiğim bir dağıtımdı. Şu anki kısa deneyimimde de ilk izlenimim olumlu yönde.

Arch Linux’la alakalı en çok duyduğum iki şey çok iyi bir topluluğunun olduğu ve wiki/forum sayfalarının birçok konuda yeterli olduğuydu. ISO imajını indirme aşamasından itibaren sadece forum ve wiki sayfalarına bakıp Google araması yapmadığımı düşündüğümde duyduklarımın doğru olduğunu söyleyebilirim. Zaten çok sık güncelleme alan bir dağıtım olduğu için Wiki sayfası dışında arama yapmak da pek önerilmiyor. Yani Arch Linux’un tavsiyesine uyduğunuz takdirde bu yazıyı okumamanız gerekiyor fakat bu yazıda anlatacaklarım ve Arch Linux hakkında ileride yazacağım yazılar Wiki sayfasında Türkçesi olmayan konular. İngilizce bilmeyen kişilerin faydalanması için yazıyorum.

netctl

netctl, terminal’den çalışan, profil temelli bir ağ yöneticisidir. Profil kelimesini özellikle yazdım, çünkü yapacağımız işlemlerde bu bilgi aklınızda bulunmalı. netctl bir Arch projesidir ve base package’da olduğu için muhtemelen sisteminizde yüklüdür fakat biz yine de işimizi garantiye almak adına netctl ve Wifi’ya bağlanmak için gerekli olan paketleri indirelim. Bunun için elbette pacman kullanacağız. Terminali açın ve aşağıdaki komutu yazın.

sudo pacman -S netctl wpa_supplicant dhcpcd dialog

Eğer bu paketlerin bilgisayarınızda olup olmadığını öğrenmek isterseniz aşağıdaki komutu yazın.

sudo pacman -Qi paketAdi

Bu komutta -Q query anlamına gelen sorgu işlemini yapar, -i ise information’dır ve o paket hakkında bilgi verir. Bu paketleri yükledikten sonra iki farklı şekilde Wifi’a bağlanmayı bağlanmayı anlatacağım.

netctl Örnek Profil Dosyasını Kullanarak

Önce netctl örnek profil dosyasını kullanmak için aşağıdaki komutu yazacağız:

sudo cp /etc/netctl/examples/wireless-wpa /etc/netctl/ornekProfilAdi

Yukarıdaki kod parçası ilk dizinde bulunan wireless-wpa dosyasını ikinci dizine kopyalar. Yukarıdaki dizin dışında bir yere kopyalamak da mümkündür fakat profil dosyaları /etc/netctl dizininde tutulur. Kopyalama işleminden sonra sudo nano /etc/netctl/ornekProfilAdi komutu ile profil dosyasını düzenleyeceğiz. Karşınıza aşağıdaki gibi bir dosya açılmış olması lazım.

Description='A simple WPA encrypted wireless connection'
Interface=wlan0
Connection=wireless

Security=wpa
IP=dhcp

ESSID='MyNetwork'
# Prepend hexadecimal keys with \"
# If your key starts with ", write it as '""<key>"'
# See also: the section on special quoting rules in netctl.profile(5)
Key='WirelessKey'
# Uncomment this if your ssid is hidden
#Hidden=yes
# Set a priority for automatic profile selection
#Priority=10

Burada değiştirmeniz gerekenleri sırasıyla yazıyorum:

Interface adınızı öğrenmek için ip link list komutunu kullanın. Output’ta listelenen isimler arasında w ile başlayan bir isim olacak. (wlp2s0 gibi) Bu isim sizin interface parametreniz olacak.
ESSID ise wifi adınız.
Son olarak key kısmına şifrenizi yazdıktan sonra Ctrl-O yapıp enter’a basıp kaydedin. Sonra ctrl+x’e basıp nano’dan çıkın.

Artık profilimiz tamam. Profili çalıştırmak için netctl start ornekProfilAdi komutunu çalıştırın ve ping -c 5 8.8.8.8 komutu ile bağlantınızı test edin. Eğer tüm adımları doğru takip ettiyseniz internete bağlanmış olmanız lazım. Fakat start komutu yalnızca bilgisayarınızı kapatana kadar geçerlidir. Bu komutu her bilgisayarınızı açtığınızda çalıştırmak isterseniz ~sudo netctl enable ornekProfilAdi~komutunu çalıştırın. İşlem bu kadar.

Profil oluşturmak için basit bir araç olan wifi-menu’yu kullanmak için komut satırına sudo wifi-menu yazın. Bu komut çevrenizdeki wifi noktalarını arayıp listeleyecek.

Bu liseten bağlanmak istediğiniz Wifi erişim noktasını seçin. Sonra size bir profil adı soracak. İstediğiniz bir adı girin. Daha sonra parolayı da girdiğinizde profil oluşturulacak ve bağlanacak. Eğer tüm adımları doğru takip ettiyseniz internete bağlanmış olmanız lazım. Fakat start komutu yalnızca bilgisayarınızı kapatana kadar geçerlidir. Bu komutu her bilgisayarınızı açtığınızda çalıştırmak isterseniz sudo netctl enable ornekProfilAdi komutunu çalıştırın.

Arch Linux’da Wifi’ya bağlanma işlemi bu kadar. Her ne kadar zor gibi gözükse de neyi neden yaptığımızı öğrendikten sonra zor sayılmaz.

Kaynak: https://wiki.archlinux.org/index.php/netctl

Merkeziyetsizlik Kavramından Ne Anlamalıyız?

Sun, 26 May 2019 13:58:50 +0000

Kripto paraların hayatımıza girmesiyle beraber merkeziyetsizlik kavramı da sıklıkla duyduğumuz kelimelerden biri oldu. Blockzincir teknolojisinden ve kripto paralardan bahsederken bu teknolojilerin merkeziyetsiz olmasını övüyoruz. Blokzincir dünyasında gün aşırı merkeziyetsiz bir uygulamanın çıktığını duyuyor ve çoğunlukla bundan mutluluk duyuyoruz. Bir çoğumuzun merkeziyetsiz internete dönüş gibi büyük hayalleri var. Peki ya bu kavramın üzerine yeterince düşündük mü? Merkeziyetsizliğe gerçekten ihtiyacımız var mı? Merkeziyetsizliği başarabildik mi? Bunu başarmak gerçekten mümkün mü?

Dünyayı şekillendireceğini düşündüğümüz bu teknolojinin vaadettiği yenilikleri iyice ölçüp tartmamız gerektiğini düşünüyorum. En azından bu yeniliklere gerçekten ihtiyacımız olup olmadığını bilirsek projelerin etiketlerinden çok hayatımıza getireceği faydaya göre değerlendirebiliriz. Yoksa adının başında decentralized yazan veya etiketinde dApp olan her proje bize güzel görünür.

Merkeziyetsizlik nedir?

Öncelikle merkeziyetsizliği anlayalım. Bu kavram Türkçede de İngilizcede de merkezin olmayışıyla kendine bir tanım bulduğu için önce merkezi olmayı tanımlayıp ondan sonra merkeziyetsizliği anlamaya çalışmak daha doğru. Bir örnekle başlayacağım. Örneğin markete gittiniz ve kasada kredi kartınızı uzattınız. Kasiyer bakiyenizin yetersiz olduğunu söyleyerek sizden başka bir kart vermenizi veya nakit ödeme yapmanızı rica etti. Fakat hesabınızda yeterli para olduğuna kesin eminsiniz. Böyle bir olayın gerçekleşme olasılığı çok düşük fakat kartı ATM’ye taktığınızda da 0 TL bakiye gördünüz. Bu durumda ne yapmanız gerekiyor? Paranızın var olduğuna emin olmanız yeterli değil, kasiyeri ikna etmeniz de anlamsız. Paranızın gerçekten var olabilmesi için bankanın ikna olması gerekiyor. Çünkü banka sistemi merkezi bir sistemdir. Yani tepedeki bir sistemin kendi altında bulunan sistemleri yönettiği, bir bilginin geçerli olmasının tek koşulunun hiyerarşinin tepesindeki aktörün bu bilgiyi doğrulaması olduğu bir sistem. Daha sıra dışı bir örnek vereyim. Bir gün yolda giderken GBT sorgusuna takıldınız ve sorguyu yapan polis memuru, sistemde TC kimlik numaranızın bulunmadığını söyledi. Yıllardır taşıdığınız bir kimlik, siz kendinizden eminsiniz fakat bu durumda sizin emin olmanız bir şey ifade etmez. Sizin, ailenizin, arkadaşlarınızın veya sizi tanıyan herkesin bu bilgiyi doğrulaması da bu bilgiyi geçerli yapmaz. Devletin, yani merkezi olan bu sistemin doğrulamadığı tüm bilgiler geçersizdir.

Merkeziyetsiz bir sistemden bahsettiğimiz andan itibaren merkezi sistemde uygulanan yukarıdan-aşağıya(top-down) doğrulama hiyerarşisi yerine yatay bir karar verme mekanizması devreye girer. Yani paranızın olduğunu ispat etmeniz gereken merkez ortadan kalkar, bunun yerine yeterli sayıda insanın sizin paranız olduğuna ikna olması gerekir. Aynı şekilde kimliğinizi doğrulamak için arkadaşlarınızın, ailenizin, sizi tanıyan kişilerin kefil olması yeterli olabilir.

Merkeziyetsizlikle karıştırılan bir kavram var, dağıtıklık. (distribution) Dağıtık bir sistemde, bilgi veya sistemin hesaplama gücü, sistemdeki düğümler arasında paylaştırılır. Buna örnek olarak DNA analizinin gerektirdiği yüksek işlem gücünün bir ağdaki bilgisayarlar arasında paylaştırılmasını verebiliz. Dolayısıyla bir sistem hem merkezi hem de dağıtık olabilir. Aynı şekilde bir sistem hem merkeziyetsiz hem de dağıtık olabilir.

Merkeziyetsizlik tanımını bitirmeden değinmek istediğim bir konu var. Ethereum’un kurucusu olan Vitalik Buterin, “The Meaning of Decentralization” adıyla yayınladığı bir yazısında üç tip merkeziyetsizlikten bahsediyor.

Mimari Merkeziyetsizlik (Architectural decentralization): Sistemdeki bilgisayar sayısıyla ve sistemin devre dışı kalan düğümlerden kaçını tolere edebileceğiyle ilgilidir.
Yönetimsel Merkeziyetsizlik (Political decentralization): Sistemdeki bilgisayarları yöneten kişi ve kurum sayısını belirtir.
Mantıksal Merkeziyetsizlik: Sistemi iki veya daha fazla parçaya böldüğümüzde sistemin buna vereceği tepkiyi ve sistemin tek bir büyük bilgisayar gibi davranıp davranmadığını kapsar.

Public blokzincirler yönetimsel merkeziyetsizdir. Çünkü herhangi kişi ve kurumun sistemi yönetme yetkisi yoktur. Aynı zamanda mimari merkeziyetsizdir çünkü mimari olarak tek hata noktası (single point of failure) yoktur. Sisteme bağlı birden fazla cihaz olduğu için her düğüm kayıt defterinin bir kopyasını tutar. Ancak tek bir bilgisayar gibi davrandığı için mantıksal merkeziyetsiz değildir.

Merkeziyetsizlik bize ne vadediyor?

Blokzincirle beraber hayatımıza daha çok giren merkeziyetsizlik kavramının dünyanın büyük çoğunluğunu heyecanlandırdığını kabul etmek lazım. Bence bunda iki büyük etken var. Birincisi merkeziyetsizliğin bize vadettikleri. Zira vadettiği şeyler birçok soruna çözüm buluyor. Diğeri ise şu, yakın zamanda Deniz Özgür’ün de ifade ettiği gibi merkeziyetsizlik kavramının içi boşaltılıyor. Çünkü birçok kişi merkeziyetsizliği sindirmeden süslü cümlelerle merkeziyetsizliği övüyor. Amaç, merkeziyetsizliğin bize vadettikleri olması gerekirken merkeziyetsizliğin kendisi bir amaç haline dönüşüyor ve ürünün sunduklarından çok tam olarak uygulanıp uygulanmadığından emin olmadığımız bir teknoloji bizi tatmin ediyor. Bu yazıda anlatmaya çabaladığım şey de bu aslında. Merkeziyetsizliğin bir araç olduğunun bilincine varmak ve bu aracın hangi sorunları çözebileceği üzerine düşünebilecek altyapıyı hazırlamak. Peki merkeziyetsizlik bize ne vadediyor?

Hata Toleransı

Karşımıza en çok çıkan argüman muhtemelen bu. Mantığı da gayet basit ve sistemin dağıtık olmasının sağladığı bir avantaj. Teknik alana çok fazla girmeden bir örnekle açıklayacağım. İnternette bir dosyayı indirmek istediğinizde sunucuda bir noktaya HTTP isteği gönderirsiniz. İletişime geçtiğiniz tek bir nokta vardır. Eğer o an o sunucu size cevap veremezse hata alırsınız. Bu hatayı telafi etmenin bir yolu yoktur. Ama merkeziyetsizliğin örneklerinden biri olan ve 2004 yılında kurulmuş olan BitTorrent, dosya paylaşımı için daha farklı bir yaklaşım kullanır. Ağdaki her cihaz aynı zamanda birer sunucudur. Dolayısıyla bir dosya indirmek için birden fazla sunucuya istek gönderirsiniz ve dosyayı bu sunuculardan parçalar halinde indirirsiniz. Eğer ağda herhangi bir sunucu dosya aktarımı sırasında ağdan düşerse başka bir sunucuya istek gönderilir. Sistemde o dosyayı barındıran hiçbir sunucu kalmayıncaya kadar indirme işlemi devam eder. Böylece yüksek oranda hata toleransı sağlar.

Buraya kadar hiçbir sorun yok. Ama hata toleransını sağlamak elbette bu kadar kolay değil. Örneğin sadece Türkiye’de kullanılan ve ülke vatandaşlarına yönelik merkeziyetsiz bir uygulama düşünün. Ülke çapında oluşabilecek bir internet kesintisinde sistem devre dışı kalacaktır. Böyle bir kesinti daha önce oldu. Dolayısıyla 82 milyon düğümlük dağıtık bir sistem dahi olsa hata toleransını başaramama ihtimali mevcut. Bu sadece ihtimallerden biri. Kısa bir beyin fırtınası ile birçok senaryo çıkarılabilir.

Saldırı Dayanıklılığı

Merkezi bir sistemde genellikle saldırı yapacağınız hedef bellidir. Bir veya birkaç sunucuya saldırı yapacaksınızdır. Dolayısıyla elinizdeki kaynakları ona uygun olarak düzenleyebilirsiniz. Örneğin herhangi bir sisteme saldırmaya yetecek kaynağınız yoksa zaafiyetlerini ararsınız ve minimum maliyetle maksimum zafiyeti yaratacağınız bir nokta ararsınız. Bu, hassas bilgilerin tutulduğu bir yer olabilir, kritik işlemlerin yapıldığı bir yer olabilir, hayal gücünüze kalmış. Fakat merkeziyetsiz bir sistemde böyle bir nokta yoktur. Eğer saldırmanız gereken bir hedef varsa bu hedef, ağın tamamı olur. Dolayısıyla saldırı dayanaklılığı büyük ölçüde artar.

Hileli İş Birliği Direnci (Collusion Resistance)

Bu başlığın Türkçe karşılığını bulmak zor olduğundan İngilizce’sini de ekledim. Hileli işbirliğinden kasıt ise şu, bir topluluğun içinde bu topluluğun çıkarlarına uygun hareket etmeyen kötü niyetli bazı gruplar olabilir. Bu oluşuma collusion diyoruz. Örnek vermek gerekirse 4054 Sayılı Rekabetin Korunması Hakkında Kanunun amaçlarından biri piyasada oluşabilecek hileli iş birliklerini(collusion) önlemektir. Buna yönelik olarak ülke sınırları içinde faaliyet gösteren ve piyasaları olumsuz etkileyecek nitelikte her türlü teşebbüsü engelleyici düzenlemeler yapar. Hileli iş birliği kelimesinin neyi kastettiğini açıklığa kavuşturduktan sonra bunu bir de merkeziyetsiz sistemler bağlamında inceleyelim.

Fikir birliği (consensus) algoritmalarında genellikle yapılan işlemin geçerli sayılabilmesi için gereken bir çoğunluk olur. 51 saldırıları da adını buradan alır. Yani ağdaki bilgisayar gücünün yüzde 50’sinden fazlasına sahip olduğunuzda sistemde double-spending yapabilirsiniz. Hatta 21 Nisan 2019’da yayınlanan bir makaleye göre Ethereum ağında 25%’lik bir işlem gücüne sahip olmanız durumunda sistemde selfish-mining zafiyetini kullanabiliyorsunuz. Yani Ethereum ağında kötü maksatlar ile bir araya gelen yüzde 25’lik bir çoğunluk ağı zafiyete uğratabiliyor. Yani merkeziyetsiz sistemlerin bu konuda tam bir dirence sahip olduğunu söyleyemeyiz. Ama bu direnç merkezi sistemlere göre daha iyi durumdadır. Dağıtıklık ne ölçüde artarsa bu iş birliğine karşı direnç o ölçüde artar. Merkezi sistemlerde ise zaten sistemde söz hakkı olan aktörlerin sayısı az veya tek olduğundan bu iş birliğine karşı direnç yok denecek kadar azdır.

Merkeziyetsizliği başarabildik mi?

Merkeziyetsizliğin bize vadettiği şeylerin bir kısmını olası eksik yönleriyle beraber inceledik. Peki şu anda merkeziyetsizliği başardık mı? Biraz da bunun üzerine kafa yoralım.

Öncelikle şunu belirtmekte fayda görüyorum. Merkezi veya merkeziyetsiz olmak siyah-beyaz gibi net bir ayrıma sahip değil. Değerlendirme yaparken “ne kadar merkezi?” veya “ne kadar merkeziyetsiz?” gibi soruları sormak daha doğru olacaktır. Bitcoin’i ele alalım. Zira merkeziyetsizlik deyince aklımıza ilk gelen örnek genelde Bitcoin oluyor. 2014 Mayıs ayında, yani bundan tam 5 sene önceki hashrate dağılımına baktığımızda GHash %32 ile başı çekiyor. Arkasından F2Pool 13%, BTC Guild 12% ile takip ediyor. Yani üç büyük aktör toplamda 57%’lik bir hashrate’e sahip. Elimizdeki en güncel veri olan 2019 Nisan verilerine baktığımızda ise 16% ile BTC.com ilk sırada. Arkasından AntPool 12%, F2Pool 11% ile takip ediyor. Yani ağdaki üç büyük aktörü topladığımızda hashrate’in yüzde 39’unu teşkil ediyor. Bu açıdan baktğımızda hashrate’in dağıtık olması açısından olumlu bir ilerleme var. Ama hayal ettiğimiz türden bir merkeziyetsizlik değil. Peki bitcoin’e ulaşma araçlarımız? Üçüncü parti bir aracıya, merkezi bir sisteme başvurmadan Bitcoin alan/alabilen kaç kişiyiz? Bu soruların cevapları aslında tam merkeziyetsizlikten henüz uzak olduğumuzu gösteriyor. Paramızı merkezi bir banka yerine merkezi bir borsada tutmamız gerçekten mantıklı mı? Kaçımız kripto varlıklarını merkezi olmayan bir yerde tutuyor? Bu sayı gün geçtikçe kesinlikle artıyor ama tatmin edici bir sayıya ulaşana kadar tam merkeziyetsiz bir sisteme sahip olduğumuzu söylemek güç. Teoride merkeziyetsiz olabilir ama pratikte merkezi sistemlere ihtiyacımızı azaltamıyorsak merkeziyetsizliğin vadettiği yeniliklerden uzağız demektir.

Kısaca toparlamak gerekirse merkeziyetsizliği başarmış sistemler var. Fakat tam anlamıyla hayal ettiğimiz seviyede değiller. Bu ivmeyle yükselen bir teknolojinin hayal ettiğimiz günlere gelmesi işten bile değil. Sadece merkeziyetsizlik fikrinin arkasında yatan sebepleri iyice sindirmemiz lazım. Bu da ancak üzerine kafa yorarak olur. Bir teknolojinin felsefi temellerinden bağımsız olarak yayılması beklenemez.

Madem merkeziyetsizlik yenilikler sunuyor, kurumlar neden merkeziyetsiz sistemlere geçiş yapmadı?

Merkeziyetsizliğin bize sunduğu yenilikleri düşündüğümüzde bu yaklaşımın hayatımızın daha çok içinde olmasını bekleriz. Fakat pratikte çok da fazla değişikliğin olduğu söylenemez. Bu da doğal olarak bir soruyu getiriyor, kurumlar neden merkeziyetsiz sistemlere geçiş yapmadı?

Merkeziyetsizlik ve blokzincir üzerine konuşulanları gözlemlediğimizde insanların sık sık yanılgıya düştüğü bir konuyla karşılaşıyoruz. Birçok kişi sırf merkeziyetsizlik fikrini benimsediği için her sektöre ve ihtiyaca uygulanabileceğini düşünüyor. Ancak durum öyle değil. Bu fikir bizi yazının başlarında bahsettiğim teknolojiyi araç yerine amaç olarak kullanma sorununa getiriyor. Eğer sistem içinde aktörlerin birbirine karşı veya aktörlerin sistem dışındaki aktörlere karşı şeffaflık ihtiyacı yoksa, gizlilik ihtiyacı yoksa, bilginin tüm aktörler arasında güncel ve doğru olması önemli değilse, bilgiyi oluşturma ve yazma yetkisi yalnızca bir merkezdeyse, aktörler arasında karşılıklı bir güven ilişkisine ihtiyaç yoksa blokzincir kullanarak merkeziyetsizlik uygulamanıza gerek yok. Biraz da blokzinciri hayatımızda neden daha fazla görmediğimize bakalım.

Bir kurumun blokzincir kullanmasının genelde üç temel sebebi olur. Hız, düşük maliyet ve merkeziyetsizlik. Fakat bu teknolojinin nispeten yeni bir teknoloji olmasından dolayı bu üç isteği de karşılamak kolay değil.
Büyük kurumlar genellikle saniyede yüzlerce işlem kapasitesine ihtiyaç duyarlar. Bunun için ölçeklenebilirliği yüksek bir zincire ihtiyaç var. Bu da blokzincirin en büyük sorunlarından biri.
Binlerce, milyonlarca lira yatırımları bir sisteme yatıracak yöneticiler bu teknolojiye tamamen güvenebilmeli. Kendini tamamen ispat edecek seviyeye gelmesine zaman olan ve yeterince olgunlaşmayan bir teknolojiye yatırım yapacak cesarete sahip olmak için bu fikri sindirebilmek lazım.

Sonuç

Bu yazıda merkeziyetsizlik ve biraz da blokzincir üzerine düşüncelerimi aktarmaya çalıştım. Bu iki kavram beni de heyacanlandırıyor fakat eleştirmeden ve eksik yanlarını aramadan bu teknolojiyi daha iyi bir seviyeye getiremeyiz. Bu sebeple biraz eleştirel yaklaşmaya çalıştım. Bir cümle ile yazdıklarımı özetlemek gerekirse, merkeziyetsizlik fikri günümüzde birçok sorunun çözümüne götürüyor bizi. Bu, bizi sorunlara tozpembe bakmaya götürmemeli. Ancak doğru değerlendirmeler yaparak bu aracı bizi doğru amaçlara götürmesi için kullanabiliriz.

Yararlandığım Kaynaklar:

Hyperledger Ekosistemindeki 13 Proje

Sat, 25 May 2019 14:06:02 +0000

Hyperledger platformunun teknoloji dünyasına girmesinin üzerinden 4 yıldan daha az bir zaman oldu. Bu süre içinde 19 Mayıs 2019 itibariyle 13 tane proje duyuruldu. Eğer merakınız varsa veya hızla gelişen bu platforma çok geç kalmadan dahil olmak isterseniz ayrıntılarıyla olmasa da yüzeysel olarak bu 13 projenin ne işe yaradığını bilmenizi tavsiye ederim.

Hyperledger’ın kendi sitesine girdiğimizde bizi “Hyperledger Serası"nı temsil eden aşağıdaki görsel karşılıyor.

Projelerin kendi sayfalarına girdiğimizde de -bence- yeni başlayan meraklı zihinlere pek de hitap etmeyen teknik açıklamalar buluyoruz. Bu yazıyı yazma amacım teknik ayrıntılardan olabildiğince arındırarak Hyperledger projelerini anlatmak. Projeleri kronolojik sıraya göre anlatacağım. Anlatacağım 13 projeden yalnızca 3 tanesi -Fabric, Sawtooth, Iroha- bir blokzincir. Diğerleri ise özelleşmiş bazı alanlarda bize kolaylık sağlayan araçlar barındırıyor. Temel kaynağım projelerin Github sayfaları ve resmi dokümanları. Bunların dışında yararlandığım kaynaklar ise sayfanın sonunda yer alıyor.

Hyperledger Fabric

Bu ekosistemin ilk projesi olan Fabric, aynı zamanda en çok bilinen proje. Hatta Hyperledger’ın Hyperledger Fabric olduğuna dair yaygın bir yanlış da var. Fabric, kurumlar için tasarlanmış kapalı blokzincir uygulamaları geliştirmeye yarayan, modüler yapıda bir framework’tür. Genel amaçlı yazılım dilleri ile geliştirme yapmaya izin veren ilk blokzincirdir. İngilizce’de plug and play adı verilen bir yapıdadır. Yani modülerdir ve uygulamanın içine amacınıza yönelik olarak hazırlanmış bileşenleri tak-çalıştır yöntemi ile ekleyebilirsiniz.

Kurumsal blokzincir gerekliliklerinde genellikle gizlilik ve kimlik doğrulaması ön plandadır. Fabric her ikisini de sağlar. Üyelik Servis Sağlayıcı(Membership Service Provider-MSP) sayesinde ağa yalnızca kimlik doğrulaması yapmış kişiler bağlanabilir. Kanallar sayesinde de kullanıcı grupları oluşturulup her gruba farklı yetki tanımları verilebilir. Böylece her veri ağdaki her katılımcının okuması/oluşturması/güncellemesi/silmesi için açık değildir.

Hyperledger bir kriptopara projesi değildir. Dolayısıyla Fabric ağı kriptopara transferi için değildir. Ağda varlıklar(asset) vardır. Bu varlıkların maddi değeri olabilir. Yalnızca veri barındıran varlıklar da olabilir.

Fabric’in çalışma prensiplerini aşağıdaki maddeler ile açıklayabiliriz:

İşlemler, chaincode’lar(smart contract) ile güvence altına alınır ve tüm katılımcılar Docker konteynırları çalıştırarak ağa bağlanır.
İşlemler kriptopara olmadan gerçekleştirilir.
Tüm işlemler gizli ve güvenlidir. Bilgiler, yalnızca ağdaki katılımcıların fikir birliği(consensus) ile güncellenir.
Tüm işlemlerin içeriği kriptoludur. Böylece içerik tüm kullanıcılar tarafından görüntülenemez.
Katılımcılar ağa erişim sağlamak için üyelik servislerine kimlik kanıtı yapmak zorundadır.

Hyperledger Sawtooth

Sawtooth, dağıtık kayıt defterleri oluşturmak, ayağa kaldırmak ve çalıştırmak için kullanılan modüler bir kurumsal blokzincir platformudur. Dikkat ettiyseniz gizlilik, kapalılık gibi bir terim kullanmadım. Sawtooth’un odak noktası kayıt defterlerini dağıtık yapmak ve akıllı kontratlar ile sistemi güvenli kılmaktır. Geçen zamanın kanıtı(proof of elapsed time-PoET) adı verilen bir consensus algoritması kullanır. Bu algoritma ile kaynak tüketimi minimize edilir.

Sawtooth ile Fabric arasındaki temel iki fark ise aşağıdaki gibidir:

Ağ tipi: Fabric’te ağa katılmak için MSP’ye kaydolup kimlik kanıtı yapmak zorunda olduğumuzdan bahsetmiştim. Sawtooth ile hem izinli hem de izinsiz blokzincirler geliştirebilirsiniz.
Gizlilik: Sawtooth’ta tüm katılımcıların ağdaki işlemleri görme yetkisi vardır. Fabric’te ise farklı yetki tanımları ile verilerin gizliliğini sağlamak mümkün.

Sawtooth’un günlük hayattaki bir uygulamasını görmek isterseniz Necati Öztaş ve Zahid Dişçi’nin çevirisini yaptığı ScanTrust projesini inceleyebilirsiniz.

Hyperledger Iroha

Iroha projesi, Japon Kaizen felsefesinden esinlenerek geliştirilmiş, adını Japonca bir şiirden almış bir dağıtık kayıt defteri teknolojisidir. Bir grup Japon yazılımcının mobil cihazlara yönelik olarak C++ dilinde geliştirdiği bir frameworktür. C++ ile yazılmış olması performans yönünden Iroha’yı ön plana çıkarıyor. Iroha deyince aklımızda gelmesi gereken iki anahtar kelime performans ve yalınlık.

Iroha kaynak, bilgi ve dijital kimlik yönetimi konusunda başarılı bir framework. Aynı zamanda bizans hata toleransını sağlayan kendi consensus algoritması var. (Yet Another Consensus-YAC)

Hyperledger Burrow

Burrow, en az Hyperledger kadar geçmişi olan bir proje. ErisDB adıyla Monax tarafından geliştirilmeye başlanmış, daha sonra da Hyperledger çatısı altına Burrow ismiyle girmiştir. Monax’ın CTO’su Casey Kuhlman, Burrow’u diğer projelerden ayıran özelliği tek bir cümle ile açıklıyor: “Burrow, Hyperledger ekosistemi içinde yalnızca bir şeyi iyi yapmak için tasarlandı: EVM (Ethereum Sanal Makinesi) akıllı kontratlarını izinli bir blokzincir ağında çalıştırmak.” Burrow üç ana bileşenden oluşuyor.

Consensus Engine: Ağdaki işlemler Bizans hata toleransına sahip Tendermint protokolü ile yapılıyor. Bu protokol ağın çatallanmasının önüne geçiyor.
İzinli EVM: Ethereum’un izinli bir ağa çevrildiğini düşünün. Aynı şekilde Solidity dili kullanılarak sağlanmış turing-complete bir sistem var.
RPC Gateway: İsminin çok teknik duruyor olması gözünüzü korkutmasın. Remote procedure call, istemcilerin(client) sunuclarla(server) haberleşmesini sağlayan bir yapı sunar. Yani kullanıcılar olarak bu gateway’i kullanarak ağ ile konuşabiliriz.

Kuhlman’ın Burrow’u anlatırken en çok üzerinde durduğu iki anahtar kelime hız ve kolaylık. Projeyi geliştirirken vadettikleri işlevselliği sunmanın yanında yazılımcılara hızlıca yaratabilecekleri bir ortamı sağlamaya çalışıyorlar.

Hyperledger Indy

Indy de Hyperledger ekosisteminde adını en çok duyduğumuz projelerden biri. Indy deyince aklımıza ilk gelmesi gereken anahtar kelime dijital kimlik. Indy, kısaca blokzincir ağı üzerinde depolanan dijital kimlikler oluşturmamızı ve doğrulamamızı sağlayan kayıt defteridir. Bu projede blokzincirlerin dağıtık yapısı ön plana çıkıyor. Bunu bir örnekle açıklayalım. Günümüzde kimlik verilerine olan bakışımız merkezi bir bakış açısı. Verilerimiz kurumlar tarafından depolanıyor ve istedikleri gibi kullanıyorlar. GDPR gibi düzenlemelerin adı geçse de buna birçoğumuz güvenmiyoruz. Bunun yanı sıra verilerimizin nasıl depolandığını da bilmiyoruz. Neredeyse hiçbir kurum verilerimizi yüksek güvenlikli bir sistemde saklayacağını taahhüt etmiyor. Örneğin Nisan 2018’de çıkan bir habere göre Facebook, milyonlarca Instagram hesabına ait parolayı düz metin olarak tutuyormuş ve bu parolalara 20000’den fazla çalışanın erişimi bulunuyormuş. Bu örnek, dijital kimliklerden bağımsız olarak verilerimizi saklayan şirketlerin ne kadar umursamaz olabileceğini hayal etmeniz içindi. Bir örnek de Türkiye’den verelim. 2016 yılında 46 milyon Türkiye Cumhuriyeti vatandaşının kimlik bilgileri internete sızdı. Şu anda da rahatlıkla ulaşılabilen bu veritabanında TC Kimlik No, ad, soyad, anne adı, baba adı, yaş, doğum yeri, doğum tarihi, nüfusa kayıt olunan il ve açık adres bulunuyor.

Indy, bu gibi sorunları tamamen çözdüğünü iddia etmiyor. Fakat ayakları yere basan bir vaat olarak dijital kimliklerde alışık olduğumuz denklemi değiştirip kimliklerimizi daha güvenli yapmayı hedefliyor. Bu yeni denklemde herkes kendi kimliğini kendisi yönetiyor. Böylece bir zafiyet milyonlarca kimliği değil bir kimliği hedef alıyor.

Hyperledger Cello

Cello, Hyperledger ekosisteminin orkestra şefi. Bundan önce bahsettiğim projelerden farklı olarak Cello, ekosistem içinde zincirleri yönetmeyi üstlenmiş bir proje. Daha teknik bir terimle ifade etmek gerekirse Cello, BaaS(blockchain as a service) aracıdır.

Şimdi yönetmek kavramını biraz daha açalım. Hyperledger’ın kurumsal bir çözüm olarak görüldüğü bir senaryoda tek bir blokzincir ağı yeterli olmayabilir. Bu durumda bu ağları yönetmek ve sürdürmek zor olacaktır. Cello ise bu zorluğu bizim için hafifletmeye çalışıyor. Cello’yu kullanarak;

Bu zincirleri farklı tipte cloud servislerinde ve container cluster’larda ayağa kaldırabilirsiniz.
Çalışan ağların yaşam döngülerine dair her işlemi yönetebilirsiniz.
Ağların loglarını, analizlerini takip edebilirsiniz.

Aynı zamanda bu işlemlerin hepsini size sunulan bir dashboard ile yapabilirsiniz.

Hyperledger Composer

Hyperledger Composer, hızlı ve kolay bir şekilde kurumsal ağlar oluşturmamızı sağlayan bir proje. Bünyesinde barındırdığı araçlarla akıllı kontratlar ve kurumsal ağ tanımı dosyaları oluşturabiliriz. Temel amacı geliştirme süreçlerini hızlandırmak olan Composer projesinin dokümanlarında aylar sürecek bir projeyi haftalar içinde bitirmenizi sağlayacağı vaadi var. Fabric ağını desteklediği için Composer arayüzü üzerinde hazırladığınız bir projeyi doğrudan Fabric ağına import edip kullanabilirsiniz.

Her ne kadar Hyperledger ekosistemi içinde bulunsa da, proje, Ağustos 2018 yılında durduruldu. Simon Stone, yaptığı yazılı bilgilendirmede projenin mimarisi genişledikçe sürdürmenin zorlaştığı gerekçesiyle projeyi durdurduklarını söyledi. Dolayısıyla production seviyesinde kullanmak doğru olmasa da bile Hyperledger Fabric ile geliştirme yapmaya başlamayı düşünen biri için iyi bir ısınma olabilir.

Hyperledger Explorer

Daha önce herhangi bir blokzincir ağının block explorer sayfasını açtıysanız bu proje size yabancı gelmeyecek. Hyperledger Explorer ile ağınıza ait birçok bilgiyi sade bir arayüz ile görebilirsiniz. Bu bilgiler arasında katılımcı sayısı, blok sayısı, işlem sayısı, chaincode sayısı, blok ayrıntıları, işlemlere ait detaylar ve grafikler var ve tüm bu bilgiler için API desteği de sağlanıyor. Backend’de NodeJS, frontend’de React, veritabanı olarak da PostgreSQL kullanılıyor.

Hyperledger Quilt

Hyperledger Quilt projesi Interledger protokolünün ekosistemdeki uygulaması. Dolayısıyla öncelikle Interledger’ı anlamak gerekiyor. ILP olarak da bilinen bu protokol, kayıt defterleri arasında para transferi yapmayı sağlıyor. Adından daha anlaşılabileceği gibi ILP bir kayıt defteri değil. Yalnızca bu kayıt defterlerinin güvenli bir şekilde mesajlaşıp para transferi yapmasını sağlayan protokol. Hyperledger da Quilt projesi ile ekosistem içinde ILP’yi uyguluyor.

Hyperledger Caliper

Bu proje hakkında anlatacak çok fazla bir şey yok. Aslında araç başlığı altında bulunan Aries, Cello, Composer, Explorer, Ursa, Quilt projeleri de tek bir amaca yönelik olarak yapılmış olduğundan ayrıntılı açıklayacak çok da bir şey yok. Caliper aracı Hyperledger ekosistemi içinde performans ölçümü yapan araç. An itibariyle(25 Mayıs 2019) Fabric, Sawtooth, Iroha, Burrow ve Composer projelerini destekliyor. Performans ölçümü için kullandığı belli başlı metrikler var. Bunlar başarı oranı, işlem ve okuma hacmi, işlem ve okuma gecikmesi, kaynak tüketimi.

Hyperledger Ursa

Ursa, topluluktaki geliştiricilerin kriptografik fonksiyonları topladığı bir proje. Blokzincir deyince aklımıza ilk gelen kelimelerden biri olan güvenlik ve kriptografi. Dolayısıyla bu proje de platform içinde önemli bir görevi yerine getiriyor. İki alt kütüphaneden oluşuyor, libursa ve libzmix. Libursa kütüphanesi dijital imzalar, anahtar değişimi, kripto gibi işlemleri yerine getirirken libzmix sıfır bilgi ispatı gibi daha karmaşık işlemleri yapıyor. Projede kriptogafi dünyasında best practice olarak kabul edilen yöntem kullanılarak yeni implementasyonlar yazmak yerine libsodium, openssl ve libsecp256k1 kütüphaneleri kullanılıyor.

Hyperledger Grid

Kurumsal blokzincir çözümlerinde belki de en çok duyduğumuz çözümler tedarik zincirleri hakkında. Grid de bu talebi karşılamak üzere geliştirilmiş bir proje. Özel olarak bir sektöre yöneldiği için Hyperledger platformunda bir ilk olma özelliğini taşıyor. Grid yalnızca bir framework, bir blokzincir değil. Sawtooth blokzincirini kullanıyor ve temel amacı tedarik zinciri uygulamalarını hızlandırmak ve kolaylaştırmak.

Hyperledger Aries

Bu proje, bazı özellikleriyle Indy ve Quilt’e benziyor fakat kapsam ve proje tanımı bakımından daha geniş bir amaç hedefliyor. Aries’in amacı blokzincir temelli dijital kimlik verilerini saklamak ve paylaşmak. Kimlik verilerini sakladığı için Indy’e benzese de bu verilerin değişimini Indy dışındaki zincirlerle de yapmayı hedefliyor. Cüzdanlar arası iletişim ve güvenli iletişim barındırdığı için de Quilt’e benziyor fakat Aries ILP protokolünü kullanmıyor ve dijital kimliklere odaklanıyor.

Yararlandığım Kaynaklar

Java Collection Framework (Türkçe)

Sun, 19 May 2019 13:56:31 +0000

Merhabalar. Bu yazımda Java Collection Framework’ten bahsedeceğim. Öncelikle Oracle’ın sitesinden Java 8 Dokümanlarını inceleyelim.

java.util paketinde yer alan collection framework’ün hiyerarşik yapısını incelediğimizde en üstte karşımıza Iterable interface’i çıkar. Bu interface’in özelliği kendisini implement eden objeyi for each döngüsünde kullanılabilir hale getirmektir. Dolayısıyla collection framework’te bulunan tüm class’ların içinde for each ile gezebileceğimiz çıkarımını yapabiliriz.

Iterable interface’inin altında karşımıza Collection interface’i çıkar. Collection, element adı verilen objelerin gruplarını temsil eder. Bazı collection’lar sıralı olur, bazıları sırasız; bazılarında tüm elementler eşsiz olur, bazılarında ise böyle bir zorunluluk yoktur. Bunları ihtiyaçlarımıza göre kullanırız.

Collection interface’inin altında ise 3 farklı interface vardır. Set, List ve Queue. Bu üç interface collection karakteristik özelliklerinin belirlendiği interface’lerdir.

1. Set

Set’in karakteristik özelliği aynı elemandan birden fazla olmasına izin vermemesi ve birden fazla null eleman kabul etmemesidir. Yani e1 ve e2 elementleri için e1.equals(e2) ise bu iki eleman aynı Set içinde barınamaz. Şimdi Set interface’inden türetilen diğer collection framework üyelerine bakalım.

HashSet

HashSet’te veriler hashleme yöntemi ile tutulur. Verilerin sırasının korunacağını garanti etmez. Yani önce e1, sonra e2 elementini kaydedip e2, e1 sırasında çekebilirsiniz. Aynı zamanda HashSet non-synchronized olduğu için birden fazla thread aynı anda bir HashSet’e erişip değiştirmeye çalışırsa problem yaşamamak için manuel bir çözüm olarak synchronized erişim sağlamalıyız.

HashSet<String> meyveler = new HashSet<String>();
	meyveler.add("Elma");
	meyveler.add("Armut");
	meyveler.add("Muz");
	meyveler.add("Çilek");

	// Aynı elementten bir tane daha eklemeye çalışıyoruz.
	meyveler.add("Armut");

	// İki tane null eklemeye çalışıyoruz.
	meyveler.add(null);
	meyveler.add(null);
	System.out.print("HashSet -> ");

	meyveler.forEach(meyve -> System.out.print(meyve + " "));

Bu kodun çıktısı bende aşağıdaki gibi oldu. Sıralama sizde daha farklı olabilir. Çünkü bildiğiniz üzere HashSet’lerde çıktı rastgele sırayla verilir.

HashSet -> null Armut Muz Çilek Elma

LinkedHashSet

HashSet’ten tek farkı, eklenen elementlerin ekleme sırasına göre tutulmasıdır. (Insertion order) Tekrarlı element eklendiğinde ilk eklenen element bundan etkilenmez.

LinkedHashSet<String> gunler = new LinkedHashSet<String>();
	gunler.add("Pazartesi");
	gunler.add("Salı");
	gunler.add("Çarşamba");
	gunler.add("Perşembe");
	gunler.add("Cuma");
	gunler.add("Cumartesi");
	gunler.add("Pazar");

	// Aynı elementten tekrar kaydediyoruz.
	// Tekrarlı element sıralamayı değiştirmeyecek.
	gunler.add("Pazartesi");

	System.out.print("LinkedHashSet -> ");
	gunler.forEach(gun -> System.out.print(gun + " "));

Bu kodun çıktısı aşağıdaki gibidir:

LinkedHashSet -> Pazartesi Salı Çarşamba Perşembe Cuma Cumartesi Pazar

TreeSet

TreeSet’lerde elementler artan sıralamayla, yani ascending order ile tutulur. null element kabul etmez. Eklenmeye çalışılırsa NullPointerException hatası verir.

TreeSet<Integer> sayilar = new TreeSet<Integer>();
	sayilar.add(4);
	sayilar.add(7);
	sayilar.add(2);
	sayilar.add(9);

	// Tekrarlı element ekliyoruz.
	// Kaydetmeyecek.
	sayilar.add(7);

	sayilar.forEach(sayi -> System.out.print(sayi + " "));

Bu kodun çıktısı aşağıdaki gibi olacaktı:

TreeSet -> 2 4 7 9

2. List

List’in karakteristik özellikleri tekrarlı elementlere izin vermesi, elementleri ekleme sırasına göre tutması ve istediğimiz index’e element eklememize izin vermesidir.

ArrayList

Collection framework’de en çok kullanılan class’tır. List özelliklerini barındırır.

ArrayList<String> sehirler = new ArrayList<String>();
	sehirler.add("Ankara");
	sehirler.add("Amasya");
	sehirler.add("Sivas");
	sehirler.add("İzmir");
	sehirler.add("Eskişehir");

	// Tekrarlı element ekliyoruz.
	sehirler.add("Amasya");

	// İstediğimiz index'e eleman ekliyoruz.
	sehirler.add(3, "Isparta");

	System.out.print("ArrayList -> ");
	sehirler.forEach(sehir -> System.out.print(sehir + " "));

Kodun çıktısı aşağıdaki gibidir:

ArrayList -> Ankara Amasya Sivas Isparta İzmir Eskişehir Amasya

LinkedList

Sonuçları bakımından ArrayList ile aynıdır. Fakat aralarında bazı farklar mevcuttur. Arama işlemlerinde LinkedList O(n) iken ArrayList’te O(1)’dir. Silme işlemlerinde ise ArrayList O(n) iken LinkedList O(1)’dir. Ekleme işlemleri de aynı sonuçları verir. Dolayısıyla eğer ekleme ve silme işlemleri sık yapılacaksa LinkedList kullanmak daha avantajlıdır. Arama işlemleri sık yapılacak ise de ArrayList daha avantajlıdır.

LinkedList<String> filmler = new LinkedList<String>();
	filmler.add("Person of Interest");
	filmler.add("Black Books");
	filmler.add("Seinfeld");
	filmler.add("Fargo");

	// İstediğimiz index'e eleman ekliyoruz.
	filmler.add(4, "Akasya Durağı");

	System.out.print("LinkedList -> ");
	filmler.forEach(film -> System.out.print(film + " "));

Kodun çıktısı aşağıdaki gibidir:

LinkedList -> Person of Interest Black Books Seinfeld Fargo Akasya Durağı

Vector

Vector, nadiren kullanılan bir classtır. Şimdiye kadar hiç kullanıldığını görmedim. Sychronized bir collection’dır ve varsayılan kapasitesi 10’dur. 11. element eklenirken kapasitesini 20 yapar. 21. elementi eklerken 40 yapar. Varsayılan kapasite ve artış değerlerini kullanıcı belirleyebilir.

3. Queue

Queue interface’i FIFO (first in first out) prensibini uygular. Yani sıraya ilk giren kişi ilk çıkar. Günlük hayattaki market sırası gibidir. Bu da çok kullanılmadığı için örnek vermiyorum.

4. Map<K,V>

Map interface’i collection sınıfına dahil değildir fakat benzer amaçlar taşıdığı aynı başlık altında öğretilir. Map’ler eşleme tablolarıdır. Bir Map’te tekrarlı key olamaz. Tüm value’lar bir key ile eşlenir ve bu key ile çağrılır.

HashMap<K, V>

HashMap’ler sıralamayı garanti etmez. null key ve null value kabul eder.

HashMap<String, String> sozluk = new HashMap<String, String>();
    sozluk.put("pencil", "kalem");
    sozluk.put("computer", "bilgisayar");
    sozluk.put("bottle", "şişe");
    sozluk.put("shoe", "ayakkabı");

    sozluk.forEach((kelimeEN, kelimeTR) -> System.out.print(kelimeEN + "-" +kelimeTR + " | "));

Bu kodun çıktısı aşağıdaki gibidir:

HashMap -> computer-bilgisayar | bottle-şişe | pencil-kalem | shoe-ayakkabı |

TreeMap<K, V>

HashMap’lerden farkı, elementleri artan sıralama (ascending) ile tutmasıdır.


TreeMap<Integer, String> alisverisListesi = new TreeMap<>();
	alisverisListesi.put(3, "Süt");
	alisverisListesi.put(4, "Yumurta");
	alisverisListesi.put(2, "Un");
	alisverisListesi.put(1, "Kakao");

	System.out.print("TreeMap -> ");
	alisverisListesi.forEach((siraNu, urun) -> System.out.print(siraNu + "." + urun + " | "));

Bu kodun çıktısı aşağıdaki gibidir:

TreeMap -> 1.Kakao | 2.Un | 3.Süt | 4.Yumurta |

HashTable<K, V>

HashMap ile benzerdir fakat aralarında bazı farklar mevcuttur. HashTable sychronized’tır, dolayısıyla performansı düşüktür. HashMap null değer alırken HashTable almaz.

Hashtable<Integer, String> menu = new Hashtable<>();
	menu.put(1, "Mercimek Çorbası");
	menu.put(2, "Alinazik");
	menu.put(3, "Pilav");
	menu.put(4, "Kola");

	System.out.print("HashTable -> ");
	menu.forEach((sira, yemek) -> System.out.print(sira + "." + yemek + " | "));

Kodun çıktısı aşağıdaki gibidir:

HashTable -> 1.Mercimek Çorbası | 2.Alinazik | 3.Pilav | 4.Kola |

Kodlara ait Github linki: https://github.com/kamer/Java-Collection-Framework

Visual Studio Code Kısayolları ve İpuçları

Tue, 07 May 2019 13:33:20 +0000

Bu yazı 7 Mayıs 2019 tarihinde yazılmıştır. Geçen sürede birçok şey değişmiş olabilir. Okumaya başlamadan önce bu durumu göz önünde bulundurmanızı tavsiye ederim.

VSCode, Sublime Text, Atom, Brackets gibi editörlerin kod yazarken işlerimizi kolaylaştırdığına şüphe yok. Fakat bu araçları daha etkin kullandığınızda verimliliğinizi daha üst noktalara taşıyabilirsiniz. Bu yazımda Visual Studio Code’da çalışmanızı yaparken bu deneyiminizi daha keyifli hale getirecek bazı kısayollar ve ipuçlarından bahsedeceğim.

Kısayollar

1. Command Palette

Visual Studio Code’daki tüm komutların bulunduğu pencere. Böylelikle kısayolları bilmeseniz bile her işinizi halledebilirsiniz. Bu yüzden tüm kısayolların adını İngilizce yazdım. Ctrl + Shift + P kısayolu ile kullanabilirsiniz.

2. Format Document

Ctrl + Shift + I kısayolu ile kullanabileceğiniz bu özellik kodunuzun girintilerini düzenleyerek estetik açıdan güzel görünmesini sağlıyor.

3. Quick Open

Proje dosyalarınız arttıkça dosyalar arasında geçiş yapmak eziyet olabiliyor. Bu özellik sayesinde farenize dokunmadan dosyalar arasında geçiş yapabilirsiniz. Tek yapmanız gereken Ctrl + P yapıp dosya adını yazmak.

4. Zen Mode

Yalnızca editörünüzün göründüğü, dikkat çekici diğer ögelerin ekranda gösterilmediği mod. Ctrl+K yapıp sonra Z’ye basmanız gerekiyor. Esc ile de eski haline dönüyor.

5. Multi-cursor Selection

Benim en sevdiğim özelliklerden biri. Aynı anda birden fazla satırı düzenlemenizi sağlıyor. Ctrl+Shift’e basılı tutup yukarı/aşağı yön tuşlarını kullanarak yapabilirsiniz.

6. Column (box) selection

Bu da multi-cursor selection’a benzer bir özellik. Kolon seçimi olarak söylenebilir. Normalde yalnızca satır seçerken bu özellik sayesinde sütunları da seçebiliyoruz. Bunun içinde Alt+Shift’e basılı tutup seçim işlemini yapmanız gerekiyor.

7. Move line up and down

Herhangi bir satırı veya seçimi mouse kullanmadan kod içinde hareket ettirmenizi sağlayan kısayol. Yalnızca bir yer seçin ve Alt’a basılı tutup yukarı/aşağı yön tuşlarını kullanın.

Anlatacağım kısayollar bu kadar. Tabii ki çok daha fazla kısayol var ve hepsini anlatmam mümkün değil. En çok kullandığım ve sevdiklerim bunlardı. Tüm bu bilgileri Visual Studio Code’un kendi sitesinden aldım. Daha fazlası için VSCode’un shortcuts cheatsheet’ini öneririm.

İpuçları

Snippet Oluşturma

VSCode’un kendi bünyesinde epey snippet var fakat bu hiçbir yazılımcı için yeterli değildir. Eğer tekrar tekrar yazdığınız kod parçaları varsa snippet oluşturmanızı tavsiye ederim. Bunun için öncelikle Ctrl+Shift+P yapın ve Configure User Snippets’e basın. Karşınıza çıkan listeden New Global Snippets File’ı seçin. Karşınıza dosya yöneticisi çıkacak. Herhangi bir isim verin ve kaydedin. Eğer her şeyi doğru yaptıysanız karşınıza aşağıdaki gibi bir ekran gelecek.

Zaten eğer dikkat ettiyseniz nasıl snippet oluşturacağınızı anlatmışlar ve örnek bir taslak koymuşlar. Doğrudan o taslağı kopyalayın süslü parantezlerin içine yapıştırın. Print to console yazan kısım snippetinizin adı. Scope değişkeninde hangi tip dosyalarda çalışmasını istediğinizi seçiyorsunuz. Prefix değişkeninde, snippetinizin size editör tarafından önerilmesi için yazmanız gereken string’i belirliyorsunuz. Mesela örnek üzerinden konuşmak gerekirse log yazdığınızda ilgili snippeti önerecek size. Body kısmı snippetinizin içeriği. Bu içerikte $1 $2 $3… şeklinde yazdığınız kısım olası değişken isimlerinin bulunacağı kısım. Yani snippet oluşturulduktan sonra Tab tuşu ile gezeceğiniz noktalar. $0 ise snippeti kullandıktan sonra cursor’ün geleceği nihai nokta. Description değişkeninde ise snippetiniz için bir tanım ekleyebiliyorsunuz. Ben for döngüsü için bir örnek yapıyorum:

"For loop": {
  "scope": "javascript",
  "prefix": "forl",
  "body": [
  "for(var i = 0; i &lt; $1; i++) { $0 }",
  ],
  "description": "Creates a for loop."
}

Bunu yazıp kaydettikten sonra snippetiniz hazır.

Emmet Eklentisi

Bu eklenti VSCode’un içinde yüklü olarak gelen bir eklenti. İçinde bulunan hazır snippetleri sayesinde birçok işinizi hızlıca halledebilirsiniz. Aslında bu yeni bir yazı yazacak kadar büyük bir konu fakat ben iki örnek verip sizi gerekli linke yönlendireceğim.

Hyperledger Composer ile Uygulama Geliştirme — 3. Erişim Kontrol Dosyası (.acl)

Sat, 04 May 2019 13:21:35 +0000

Gereklilikler

Serinin önceki yazılarını okuduysanız ekstra bir gerekliliğe ihtiyaç yoktur. Elimden geldiğince yeni başlayan insanlara hitap edecek şekilde açıklamaya çalışıyorum.

1. Giriş

Merhaba. Model dosyasını oluşturmayı ve modelleme dilini öğrendikten sonra sırada erişim kontrol dosyası (access control file, .acl) var. Öncelikli bu dosyaya neden ihtiyaç duyduğumuzu açıklamakta fayda var. Bunun için blokzinciri temellerine dönüp izinli ve izinsiz blokzincirlerin farkını anlamamız lazım. Deniz Özgür’ün Türkçeye kazandırıp Hyperledger’a Giriş adıyla yayınladığı resmi dokümanda bu farka dair şu kelimeler geçiyor:

Çoğu kripto para birimi, herkesin katılabileceği ve kullanmak için tam haklara sahip olduğu izinsiz blok zinciri kullanır. Örneğin herkes Bitcoin veya Ether’ı satın alabilir, çünkü bunlar açık, izinsiz teknolojilerdir.

Öte yandan, işletmeler izinli blok zincirler kullanma eğilimindedir. Bu, bir kişinin blok zincirinde belirli eylemleri gerçekleştirmek için belirli gereksinimleri yerine getirmesi gerektiği anlamına gelir. Bazı izin verilen blok zincirleri, önceden kimliklerini belirtmiş ve onaylatmış kişilere bile erişimi kısıtlayabilirler. Diğerleri herkesin katılmasına izin verir, ancak yalnızca güvenilir kimliklerin blok zincirindeki işlemleri doğrulamasına izin verirler.

Yukarıdaki tanımlar ışığında erişim kontrol dosyası gerekliliğini daha rahat açıklayabiliriz. Örneğin, bir tedarik zincirini Hyperledger ile tasarladığınızı düşünün. Bu zincir üzerinde isteyen herkesin işlem yapabiliyor olması saçma olurdu değil mi? Hatta birçok senaryoda bu zincirin herkes tarafından görülmesi de yanlış bir kullanım şekli olabilir. Dolayısıyla belirli bir kullanıcıya veya kullanıcı grubuna tanımlanmış özel yetkiler olmalı. Erişim kontrol dosyası bize bu yeteneği kazandıran dosyadır. Kendine ait anlaşılması basit bir söz dizimi(syntax) vardır. Yine yazımın giriş kısmını sağlam temellere oturtmak için resmi dokümandaki tanımı irdelemek istiyorum. Resmi dokümanda ACL hakkında aşağıdaki cümle yer alıyor.

By defining ACL rules you can determine which users/roles are permitted to create, read, update or delete elements in a business network’s domain model.

by defining ACL rules: .acl dosyasını oluştururken yaptığımız şey bir takım kurallar oluşturmaktır.
which users/roles are permitted to create, read, update, or delete elements: Buradaki ifade gayet açık ve net. ACL kurallarının içeriği, kullanıcıların ve kullanıcıların ait olduğu rollerin yapabilecekleri CRUD işlemlerinin(oluşturma, okuma, güncelleme ve silme) kapsamını belirleyecek şekilde olmalı.
in a business network’s domain model: Bir önceki yazıyı okuduysanız bu ifade sizin için yabancı bir şey değil. Composer modelleme dili kullanarak oluşturduğumuz modele domain model demiştik. Yani ağ üzerinde tüm kaynakların tanımlandığı model. Oluşturduğumuz kurallar da bu kaynaklar üzerinde olacaktır elbette.

Bu dosya projenin kök dizininde permissions.acl adıyla bulunur. Eğer bu dosyayı oluşturmazsanız tüm yetkiler serbest olur.

2. Sistem Erişim Kuralları Belirlemek

Daha önce bahsettiğim üzere sistem varlıkları org.hyperledger.composer.system.cto adresinde bulunuyor. Sistem Erişim Kurallarına örnek olarak ağ erişimini verebiliriz. system.cto dosyasında aşağıdaki satırlar mevcut:

asset Network identified by networkId {
  o String networkId
  o String runtimeVersion
}

Ağ kuralı belirlemek için ise aşağıdaki satırları yazıyoruz.

rule AgErisimYetkisi {
  description: "Yöneticiler ağ komutlarına erişebilir."
  participant: "org.hyperledgertr.proje.Yonetici"
  operation: ALL
  resource: "org.hyperledger.composer.system.Network"
  action: ALLOW
}

Yukarıdaki kural üzerinden söz dizimini inceleyelim. İlk satırda kuralımızın adını giriyoruz. Description kısmında kuralın açıklamasını giriyoruz. Participant kısmında kuralı uyguladığımız katılımcı ya da katılımcı grubunu seçiyoruz. Operation’da hangi işlemleri uygulayabileceğini seçiyoruz. Resource, participant kısmında seçtiğimiz katılımcının/katılımcı grubunun erişebileceği/erişemeyeceği kaynakları belirttiğimiz kısım. Action’da ise kuralın türünü seçiyoruz. Burada ALLOW diyerek izin vermişiz. DENY seçeneği ile bu erişimi engelleyebilirdik. Eğer ağdaki tüm kaynaklara erişim vermek istersek de org.hyperledger.composer.system.* yazabiliriz. Sisteme ait diğer yetkilere ulaşmak için system.cto dosyasına veya resmi dokümandaki tabloya bakabilirsiniz.

3. Koşullu Erişim Kuralları

Yukarıda sistem erişim kuralları tanımlarken dokümanda “simple ACL rule” olarak geçen basit bir kural tanımlaması yaptık. Diğer bir yöntem ise bu kuralı bazı koşullara dayandırmak. Henüz kendim kullanmadığım için doğrudan dokümanda yer alan örneği paylaşıyorum.

rule SampleConditionalRule {
  description: "Description of the ACL rule"
  participant(m): "org.example.SampleParticipant"
  operation: ALL
  resource(v): "org.example.SampleAsset"
  condition: (v.owner.getIdentifier() == m.getIdentifier())
  action: ALLOW
}

Gördüğünüz üzere bu kuralda katılımcı için m, kaynak için ise v değişkeni seçilmiş ve condition kısmında boolean tipinde değer döndüren birJavaScript koşulu yazılmış. Bu kurala göre SampleAsset adındaki varlıklara yalnızca sahiplerinin erişim yetkisi bulunmakta.

rule SampleConditionalRuleWithTransaction {
  description: "Description of the ACL rule"
  participant(m): "org.example.SampleParticipant"
  operation: READ, CREATE, UPDATE
  resource(v): "org.example.SampleAsset"
  transaction(tx): "org.example.SampleTransaction"
  condition: (v.owner.getIdentifier() == m.getIdentifier())
  action: ALLOW
}

Bu da resource, participant ve transaction içeren örnek bir kural.

4. Kural Alanlarının Ayrıntılı Açıklaması

Operation: Kuralın geçerli olduğu eylemi belirtir. 5 değer alabilir. CREATE, READ, UPDATE, DELETE, ALL. Birden dazla eylem varsa aralarında virgül kullanarak belirtilir.

Participant: İşlemi gerçekleştirecek olan kişi veya kurumu belirtir.

Transaction: Katılımcının belirtilen kural dahilinde gerçekleştirebileceği işlemi ifade eder.

Condition: Boolean değer döndüren bir JavaScript ifadesi alan condition alanı, kuralları şarta bağlamak için kullanılır. JavaScript’te if(...) içine yazılabilecek her şeyi değer olarak alabilir.

Action: İki değer alabilir, ALLOW ve DENY. Kural, bu alana bağlı olarak kapsamını daraltır.

Giriş seviyesinde, Hyperledger Composer.acl dosyasına dair söyleyebileceklerim bundan ibaret. Bu konuyu daha iyi anlamak için örnek .acl dosyalarına göz atmak faydalı olabilir.

Kaynak: Hyperledger Composer Resmi Dokümanı

Hyperledger Composer ile Uygulama Geliştirme — 2. Composer Modelleme Dili (.cto Dosyası)

Tue, 23 Apr 2019 13:16:28 +0000

Merhaba. Bir önceki yazımda uygulamadaki olası aktörlerden ve bunları nasıl tanımlayacağımızdan, Kurumsal Ağ Tanımından(Business Network Definition) ve Kurumsal Ağ Tanımının bileşenlerinden bahsetmiştim. Bu yazıda ise Model dosyasının söz diziminden (syntax) bahsedeceğim.

Gereklilikler

Bu yazıdaki herhangi bir gereklilik bulunmamaktadır. Temel seviyede yazılım ve veritabanı bilgisi konuyu anlamanızı kolaylaştıracaktır.

1. Giriş

Model dosyası, uygulamamızdaki katılımcıları, varlıkları ve işlemleri tanımladığımız .cto uzantılı dosyadır. Konuya ilişkin gözden kaçan kavram olmasın diye resmi dokümandaki modeling language tanımını beraber irdeleyelim. Tanıma ilişkin yapacağım açıklamalar büyük oranda yazılım bilgisi yeterli seviyede olmayan kişilere yöneliktir. Bilgi seviyenizin yeterli seviyede olduğuna inanıyorsanız giriş bölümünün bundan sonraki kısmını okumadan diğer bölüme geçebilirsiniz.

“Hyperledger Composer includes an object-oriented modeling language that is used to define the domain model for a business network definition.”

object-oriented modeling language ifadesi, yazılım dünyasından birçoğumuzun aşina olduğu ve Türkçeye nesne yönelimli modelleme dili olarak çevrilebilecek bir kavram. Modelleme dili zaten adından anlaşılabilecek basitlikte bir kelime. İrdelememiz gereken kısım bu modelleme dilinin nesne yönelimli olması. En net ve kısa ifadeyle yazılım geliştirirken yaptığımız şey genelde dünyadaki bazı olguları koda çevirmektir. Bu çevirme işlemi sırasında nesne yönelimli bir dil kullanıyorsak her şey bizim için bir nesnedir. Her nesnenin bazı özellikleri (attribute) ve davranışları (behaviour) vardır. Biz bu nesnelerin birbiriyle olan ilişkilerini düzenleriz. Yazdığımız kodla yaratacağımız dünyada bakış açımız buna göre olur. Örneğin bir kütüphane otomasyon sistemi yapacaksınız. Kitaplar ve kütüphane üyeleri birer nesnedir. Üyelerin kimlik numarası, isim soyisim, doğrum tarihi gibi bilgileri özellik, kitap ödünç alma, ödünç aldığı kitabı iade etme gibi eylemleri davranıştır. Kitaplar da aynı şekilde nesnelerdir, ISBN numarası, adı, yazar adı, basım yılı gibi özellikleri vardır. Otomasyonda da genellikle yapılacak şey üye nesnesinin kitap nesnesiyle olan ilişkisini kurmak ve düzenlemek olacaktır.
domain model for a business network definiton ifadesindeki domain model, yazılım tasarımının temelidir. Gerçek dünyadaki varlıkları ve bu varlıkların birbiri arasındaki ilişkiyi tanımladığımızda çıkardığımız model domain model’dir. Hyperledger Composer’da bu modeli kurumsal ağ tanımı (business network definition) için yaparız.

Yukarıda bahsettiğim birkaç kavramı iyice anladıktan sonra tanıma genel bir açıklama getirmekte fayda var. Hyperledger Composer’ın kurumsal ağ tanımına gerçek hayattaki bir modeli, bir problemi anlatmamız gerekiyor. Bu bir tedarik zinciri olabilir veya bir sertifika/belge yönetimi olabilir. Gerçek hayatta bu modelin bazı aktörleri, aktörlerin birbirleri arasındaki ilişkileri ve özellikleri vardır. Bu modeli nesne yönelimli modelleme dili ile Hyperledger’a aktardığımız dosya, model dosyasıdır.

.cto uzantılı olan bu dosya üç temel bileşenden oluşur:

namespace tanımlaması.
Uygulamamızdaki kaynakların tanımlaması.
- Varlıklar (assets)
- İşlemler (transactions)
- Katılımcılar (participants)
- Olaylar (events)
(Opsiyonel) Diğer namespace’lerden kaynak almak.(import)

2. namespace Tanımlamak

Uygulamamızda aynı amaç için bir araya getirdiğimiz tüm kaynakların oluşturduğu kümeye namespace denir. Bu namespace içinde tüm kaynaklar eşsiz olarak tanımlanır. Herhangi bir namespace’e ait olan bir kaynağa erişmek için o kaynağı namespace’in adıyla çağırırız. Çünkü aynı isme sahip olan ve farklı namespace’lerde bulunan iki varlık birbirinden farklıdır. Biyolojideki isimlendirmeler gibi düşünebiliriz. Örneğin mangifera indica mango demekken, apis indica bir bal arısı türüdür. Yazımı gayet basittir. Örnek olarak:

namespace org.hyperledgerturkiye.ornekuygulama

Burada tanımlamayı istediğiniz şekilde yapabilirsiniz. Fakat genelde org’den sonra organizasyon, şirket veya proje ismi; sonrasında genelden özele doğru inen bir adlandırma tercih ediliyor. Benim verdiğim örnekte org.organizasyonİsmi.projeİsmi şeklinde bir tanımlama var. Birden fazla namespace eklemek isteseydim ona göre tanımlamamı değiştirebilirdim. Örneğin,

namespace org.hyperledgerkiye.ornekuygulama.alimSatim

Bu namespace içindeki bir kaynağa ulaşmak içinse aşağıdaki şekilde bir yazım kullanıyoruz.

org.hyperledgerturkiye.ornekuygulama.alimSatim.ilan

Yazım şekline dair bahsedeceklerim bu kadar. İki tane uyarı yapıp bir sonraki bölüme geçelim:

İnternette, özellikle IBM’in örneklerinde, “org.acme…." şeklinde tanımlamalar görmeniz muhtemeldir. Acme kelimesi başta bir kural veya dile ait bir şey gibi hissettirdiği için kafanız karışabilir. IBM’in bu gibi örnekler verirken kullandığı hayali lojistik firmasının adı Acme Freight’tir. Yani acme yerine kendi organizasyonunuzu yazabilirsiniz. Github’da bu konuda dert yanıp issue açanlar olmuş fakat hala acme örneği yaygın olarak kullanılıyor.
Sizin oluşturduğunuz namespace dışında Hyperledger Composer’ın kendine ait bir namespace’i de vardır. Adı system namespace olan bu namespace, asset, event, participant ve transaction değişkenleri için temel tanımlamaları içerir. Bu tanımlamalar soyut (abstract) tiptedir ve oluşturduğunuz tüm değişkenler bunları extend eder. Bu soyut tanımlamalarda participant ve asset için değer yoktur. Fakat event ve transaction tanımlamalarında

eventId veya transactionId ve timestamp değişkenleri vardır. Bu demek oluyor ki eğer tanımladığınız herhangi bir participant veya asset içinde bu değişkenler bulunuyorsa silmeniz gerekir. System namespace’in .cto dosyasını Github’da bulabilirsiniz.

3. Kaynakları Tanımlamak

3.1. Sınıf Tanımlamaları (Class Definitions)

Hyperledger Modelleme dilinde asset, participant, transaction ve event tanımlamaları sınıf tanımlamasıdır. Daha önce belirttiğim gibi ağdaki kaynaklar eşsiz olmak zorundadır. Hepsinin kendine ait eşsiz bir değişkeni vardır. Event ve transaction sınıflarının system namespace’deki soyut (abstract) sınıflarında eventId ve transactionId değişkenleri bulunduğu için onları eşsiz yapan ekstra bir tanımlayıcıya ihtiyaç duymazlar. Bu yüzden participant ve asset sınıflarını tanımlarken onları eşsiz yapan bir değer belirtmek zorundayız. Aşağıda örnek sınıf tanımlamalarını görebilirsiniz.

asset Sertifika identified by sertifikaId {
    ...
    ...
    ...
}

Yukarıda tanımladığımız Sertifika asset’ini eşsiz yapan değer sertifikaId’dir. Değişken tanımlama kısmına gelmediğimiz için henüz sertifikaId’nin nasıl tanımlanacağını yazmadım. Participant tanımlamasında da aynı söz dizimini kullanılır.

transaction Onay {
    ...
    ...
    ...
}

Yukarıdaki Onay transaction’ınında asset ve participant tanımlamasından farklı olarak yalnızca eşsiz bir değer vermedik. Event tanımlaması da transaction ile aynı formatta olacaktır.

Son olarak sınıflar arasında kalıtım da sağlanabilir. Yani bir sınıfı başka bir sınıfın alt sınıfı olarak tanımlayıp üst sınıfın sahip olduğu tüm değişkenleri alt sınıfta kullanabiliriz. Bu birçok yazılım dilinde bulunan bir özelliktir. Örneğin:

asset Telefon identified by imei {
    o String imei
}

asset AkilliTelefon extends Telefon {
    o String marka
    o String model
}

Yukarıda iki asset tanımladık. Telefon asset’i AkilliTelefon asset’inin üst sınıfı olduğu için imei değişkeni AkilliTelefon’a kalıtım ile geçmiş oldu. Bunu soyut sınıflarla da yapabiliriz. Soyut sınıfların tek farkı diğer sınıflar gibi nesne oluşturmazlar. Yalnızca kalıtımla değişken veren üst sınıf olarak görev alırlar.

3.2. Değişken Tanımlamaları (Variable Definitions) Değişkenler, veya alanlar(fields), sınıfların sahip olduğu özellikleri tanımlamaya yarar.

Değişkenleri iki şekilde tanımlayabiliriz.

Owned Property (Sahip olunan değişken): Başındaki ‘o’ harfiyle ifade edilen owned property’ler içinde bulunduğu sınıftan türetilen nesnelere ait olur. Yani bu nesne silindiğinde bu değişkenler de o sınıfla beraber silinir.
Related Property (Bağlı Değişken): Başlarındaki –> karakterleriyle ifade edilirler. Bu değişkenler sınıfa ait değildir. Varolan bir değişkenle ilişkilendirilmiş bir alanı ifade eder. Yazılım dillerindeki pointer’ın Hyperledger Composer Modelleme Dilindeki karşılığı olduğu söylenebilir. Yani başında –> karakterleriyle tanımladığımız değişkenler pratikte içinde veri tutmaz. Yalnızca varolan bir değişkenin adresini tutar. Dolayısıyla bu değişkenleri barındıran sınıflar silindiğinde asıl değişken silinmez.

Aşağıda modelleme dilindeki olası değişken tiplerini göreceksiniz:

asset OlasiTumDegiskenler identified by id {

    // Standart UTF8 String değişken.
    o String id;
    // Default değer verebiliyoruz.
    o String paraBirimi default="TL"
    // Numerik değerlere aralık verebiliyoruz.
    o Integer yas range[18,]

    // Dizi tanımlayabiliriz.
    o Integer[] integerArray
    // 64 bit Double değişken.
    o Double ortalama
    // 64 bit Long değişken.
    o Long not
    // Regex pattern ile kısıtlayabiliriz.
    o String isim regex = [a-zA-Z]
    // Boolean değer.
    o Boolean isTrue
    // Tarih.
    o DateTime createdDate
    // Opsiyonel değişken
    o DateTime updatedDate optional
}

3.2. Numaralandırılmış Türler (Enumerated Types)

Yalnızca n adet olası değeri olan tiplerdir. Örneğin haftanın günleri yalnızca 7 tane olabilir. Haftanın günlerine ait enum’ımızı tanımlayalım:

enum HaftaninGunu {
  o PAZARTESI
  o SALI
  o CARSAMBA
  o PERSEMBE
  o CUMA
  o CUMARTESI
  o PAZAR
}

Bu enum’ın sınıf içindeki kullanımı da aşağıdaki gibidir.

asset Etkinlik identified by id {
  o String id
  o HaftaninGunu etkinlikGunu
}

3.2. Konseptler (Consepts)

Konseptler, asset, participant veya transaction olmayan soyut sınıflardır. Anlatmak yerine kod üzerinde göstermek daha anlaşılır olacağından iki örnek vereceğim.

concept AdresBilgisi {
  o String SokakCadde
  o String Mahalle
  o String Sehir
  o String Ilce
  o String Semt
  o String BinaNo
  o String KapiNo
}

participant Personel identified by tc {
  o String tc
  o AdresBilgisi adresBilgisi
}

Bu birinci örnek. Diğer örnek de concept’ler arasındaki kalıtım üzerine.

abstract concept AdresBilgisi {
    o String SokakCadde
    o String Mahalle
    o String Sehir
    o String Ilce
    o String Semt
    o String BinaNo
    o String KapiNo
}

concept YabanciAdres extends AdresBilgisi {
    o String Ulke
}

3.3. İlişkiler (Relationships)

Composer’da ilişkiler, üç bileşenden oluşan veri gruplarıdır.

Namespace
Tip adı
Nesnenin tanımlayıcı (identifier)

Örneğin

org.hyperledgerturkiye.ornekuygulama.alimSatim.Satici#12345678901

yazdığımızda

org.hyperledgerturkiye.ornekuygulama.alimSatim namespace’inde bulunan,
Satici participantına ait,
12345678901 TC Kimlik numaralı kişiyi referans göstermiş oluyoruz.

4. Import

Diğer namespace’lerden kaynak almak için import anahtar kelimesini kullanırız. Bunun için .cto dosyamızın başına

import org.hyperledgerturkiye.muhasebe.Fatura

şeklinde bir tanımlama yaparız. Eğer bir namespace içindeki her şeyi istersek de

import org.hyperledgerturkiye.muhasebe.*

yazarız.

Kaynaklar

Hyperledger Composer ile Uygulama Geliştirme — 1. Temel Kavramlar

Fri, 19 Apr 2019 13:01:14 +0000

İçerik

Bu yazı serisi, Hyperledger Composer’da proje yapmak isteyenlere yönelik olarak hazırlanmıştır. Temel konseptlerde ısınma yapıp sonra örnek bir uygulamayı adım adım beraber geliştireceğiz. Yazımda temel kaynağım Hyperledger Composer’ın resmi dokümanlarıdır.

Gereklilikler

Temel kavramlardan bahsettiğim bu kısımda herhangi bir gereklilik bulunmamaktadır. Sadece daha iyi anlamak açısından Hyperledger’ın ve blokzincir teknolojisinin ne olduğunu bilmek artı olacaktır.

Temel Kavramlar

Hyperledger Composer ile geliştirme yaparken bazı kavramlarla karşılaşacaksınız. Yabancılık çekmemeniz açısından kavramların bir kısmını bu başlık altında topladım. Daha önce blokzincir hakkında okumalar yaptıysanız bir kısmına aşina olabilirsiniz.

Varlıklar(Assets): Varlıklar, ağda kayıtlarda bulunan mülkleri, servisleri ve eşyaları ifade eder. Varlık tanımı kurumsal ağda birçok şeyi ifade edebilir. Örneğin tapu, satılık bir ev, oy verme sisteminde verilen bir oy, sertifika olabilir. Varlıklar eşsizdir.

Katımcılar(Participants): Katılımcılar, tüm işlemleri gerçekleştiren ve varlıklara sahip olan ağ üyeleridir. Bir kişi veya organizasyon katılımcı olabilir. Katılımcılar da varlıklar gibi eşsizdir.

İşlemler(Transactions): Katılımcıların ağ üzerinde yaptığı her faaliyet işlem(transaction) olarak değer kazanır ve ağa kaydedilir. Transactionlar silinemezler ve değiştirilemezler. Dolayısıyla geçmişe yönelik olarak tarama yapabilirsiniz.

ID Kartları(ID Cards): Katılımcıların sahip olduğu eşsiz kimliktir. Hem katılımcıları tanımlamaya hem de ağa daha kolay bir şekilde bağlanmalarını sağlamaya yarar.

Bu dört kavramı pekiştirmek için bir örnek yeterli olacaktır. Hyperledger Composer ile yapacağınız bir oy verme uygulamasında seçmenler katılımcı, oy verdikleri partiler varlık, verdikleri oylar ise işlem olacaktır. Seçmenleri ağda tanımlanmak için ise kimlik bilgilerini de barındıran bir ID kart kullanılacaktır.

Kurumsal Ağ Tanımı (Business Network Definition)

Kurumsal ağ tanımı dört şeyden oluşur:

Model Dosyası (.cto)
Script Dosyası (.js)
Erişim Kontrol Dosyası (Access Control File - .acl)
Sorgu Dosyası (Query File - .qry)

Model Dosyası(.cto)

Model dosyası, Hyperledger Composer Modelleme Dilini kullanan ve ağ katılımcılarını(participants), varlıkları(assets) ve işlemleri(transactions) tanımlamamıza yarayan dosyadır. Kendine ait nesne yönelimli bir söz dizimi ve formatı vardır. Bir sonraki yazıda ayrıntılı olarak değineceğim.

Script Dosyası(.js)

Script dosyaları, daha önce de belirttiğim üzere, projemizin logic kısmını üstleniyor. Varlıkların transferini script dosyaları ile yapıyoruz. Örneğin katılımcıların herhangi bireyler, varlıkların ise satılık evler olduğu senaryoda bireylerin evi satın alması işlemini js dosyaları ile sağlıyoruz.

Erişim Kontrol Dosyası (Access Control File - .acl)

Adından tahmin edebileceğiniz üzere kullanıcıların veya grupların ağdaki yetkilerini tanımladığımız dosyadır. Hyperledger, permissioned bir blokzincirdir ve bu özelliğini uyguladığımız yer bu dosyadır. Ağda herkesin yetki kapsamı aynı olmayabilir. Örneğin araba satış ilanları eklediğimiz bir zincirde fiyatları herkes görebilirken fiyat indirimini yalnızca bir kişi yapabilir. Aynı şekilde eğer ilanda uygun olmayan bir yazı girildiyse bunu herkes görebilirken yalnızca ilan sahibi ve bir grup editör düzeltebilir. Bunu yetki kontrolünü .acl dosyası içinde namespace’ler ile yapıyoruz.

Sorgu Dosyası (Query File - .qry)

Blokzincirde bulunan veriler üzerinde sorgu yapmak için kullandığımız dosyadır. Kendine ait bir formatı vardır fakat daha önceden SQL kullandıysanız yabancılık çekmeyeceğiniz bir formattır. Yazılım dünyasında “named query” olarak geçen terimin Hyperledger karşılığı olduğunu söyleyebiliriz. İsim verdiğimiz bazı hazır sorguları .qry dosyası içine koyarız ve bunu Business Network Definition içinde Fabric’e veririz. Sonra bu sorgulara Rest API ile ulaşabiliriz.

Kurumsal Ağ Tanımı Ne İşe Yarar?

Yukarıda kurumsal ağ tanımının bileşenlerinden bahsettik. Dört temel bileşen ile ağımızı tanımladıktan sonra ağ tanımını .bna uzantılı bir arşiv dosyası olarak alıyoruz. Artık bu .bna dosyasını kullanarak uygulamamızı deploy edebiliriz. İşte tam bu noktada Hyperledger Composer’ın bize sunduğu avantajı hissedebilirsiniz. Hyperledger Composer, resmi dokümanda da yazdığı üzere, blokzincir uygulamalarımızı daha hızlı ve pratik bir şekilde hazırlamamız için bize bir takım araçlar sunan bir proje. Örneğin bu dört bileşeni hazırladıktan sonra oluşturduğumuz .bna dosyası bize doğrudan projemizi deploy edecek yeteneği sağlıyor. Bunu da Hyperledger Fabric ile yapıyoruz. Sonraki yazılarda buna da değineceğim.

Yukarıda anlattığım şeylerin özetini aşağıdaki diyagramda bulabilirsiniz.

Kaynak: https://hyperledger.github.io/composer/latest/introduction/introduction.html

Başarılı Yazılımcıların 14 Alışkanlığı-1

Tue, 16 Apr 2019 12:53:39 +0000

Not: Bu yazı bana ait değildir. dev.to sitesinde yayınlanan ve Paul Isaris’e ait olan “The 14 habits of highly effective developers (Part 1)” başlıklı yazının çevirisidir. Çeviri için kendisinden izin alınmıştır.

Giriş

Bir çok kişi, başarılı bir Junior yazılımcıdan mid-level (orta seviye) bir yazılımcıya geçiş yapmanın zaman ve tecrübe işi olduğunu düşünüyor.

Aslında bu iki tip yazılımcıyı birbirinden ayıran çizgi ince bir çizgi ve kişiye göre değişkenlik gösteriyor. Bu yazı, hiç bitmeyen “Orta seviye bir yazılımcıyı tam olarak ne tanımlar?” tartışması üzerine daha fazla şey söylemeyecek.

Dürüst olmak gerekirse birinin düşünce yapısını değiştiren ve Junior seviyeden orta seviyeye geçiren şeyin alışkanlıklar olduğuna sıkı bir şekilde inanıyorum.

Alışkanlıklar, sistematik olarak yaptığımız ve bize garip gelmeyen doğal davranışlardır. Kodla ve işle alakalı alışkanlıklar edinmek profesyonel ve kişisel gelişim için kritik öneme sahiptir.

Uzmanlaştığınızda daha verimli bir şekilde gelişim sağlayacağınız ve bir sonraki seviyeye geçmenize yardım edecek alışkanlıklara bakalım.

1. Küçük metotlar yazın

İdeal olanı 20–30 satırdan daha uzun olmamasıdır. (LoC: Line of code) Bu alışkanlık son derece önemlidir. Sizi yalnızca daha derli toplu kod yazmaya zorlamaz, aynı zamanda kodunuzu modülarize etmeye başladığınızda analitik düşünmenize yardımcı olur. İçinde çok fazla if’in, for döngüsünün olduğu çok girintili büyük bir metotla uğraşmak tam bir kabus gibidir. Böyle bir metodu yazarken çok kolay ve anlaşılır geliyor olabilir ama birkaç gün sonra bile o metodun ne iş yaptığını anlamanız çok zor olacaktır.

Üstüne üstlük büyük metotlar çoğunlukla yeniden kullanılabilir değildir. Yalnızca bir projedeki özel bir ihtiyaca hizmet etmek üzere yazılırlar ve başka yerde kullanılmaları zordur.

2. Anlamlı isimler verin

Hem metotlara, hem de değişkenlere anlamlı isimler verin. Mid-level (orta seviye) bir yazılımcının “x”, “xyz” veya “object” gibi isimlere sahip değişkenler yazması makul değildir. Değişkenlerin İngilizce (veya Türkçe) kelimelerle isimlendirilmesinin amacı anlamlı olmalarıdır.

Kodunuzla iletişim kurmanız dokümanlarla veya comment’lerle iletişim kurmanızdan çok daha önemlidir.

Comment’lerin amacı “nasıl”‘ı değil, “neden”‘i cevaplamaktır.

Anlamlı değişkenlere sahip olmanız kodunuzu okuyan kişiyle daha iyi bir iletişim kurmanıza yardımcı olur ve aynı zamanda haddinden fazla comment yazma ihtiyacınızı azaltmış olursunuz. Bu, hem değişkenler hem de metotlar için geçerlidir. Ayrıca bir metotu isimlendirmek sizi çok uğraştırıyorsa metodu basitleştirmek için kodunuzu refactor etmeyi de düşünün. Çünkü iyi ve temiz yazılmış bir metota isim bulmak, karmaşık bir metota göre daha kolaydır.

İsimlendirmeyle boğuştuğunuzda bir an için durun ve isimlendirmeye çalıştığınız bileşenin çok karmaşık olduğunu ve refactoring’e ihtiyacı olduğunu düşünün.

3. Çok fazla parametre kullanarak metodunuzu karmaşıklaştırmayın

Metodunuzda çok fazla parametre olması refactoring yapmanız gerektiğine bir işarettir. Bu tarz metotlar yazmak çoğunlukla SRP’ye (Single Responsibility Principle / Tek Sorumluluk Prensibi) aykırıdır. Yani metodunuzun çok fazla sorumluluğu olur ve çok fazla iş yapar. Etkili ve temiz bir metot, bir işi iyi bir şekilde yapan metottur. Uncle Bob‘a göre bir metot için en fazla üç parametre makul sayılabilir. Bu görüş bu kadar katı olmasa da bir metot için arzu edilen parametre sayısı konusunda size bir fikir verebilir.

Metodunuzun lokal parametrelerini class field’lara çevirmeyin. Kodunuzu refactor etmeyi veya metodunuzu iki parçaya bölmeyi ve metotlarınıza daha az iş yaptırmayı ihmal etmeyin.

Fonksiyonların çok az parametresi olmalı. Parametresiz olması en iyisi, sonra bir parametreli, iki parametreli ve üç parametreli. Üçten fazlası ise güvensizdir ve peşinen uzak durulmalıdır.

— Robert C. Martin

4. Bir sınıfta çok fazla metot tanımlamaktan kaçının

Parametre sayısının yanısıra bir sınıftaki metot sayısı da önemlidir. Çok fazla metodun olduğu büyük sınıflar genellikle o bileşenin çok fazla şey bildiğine veya çok fazla şey yaptığına işarettir. Bu tarz bileşenlerin yüksek bağlılıklı olarak anti-pattern bir yapıda yazıldığını ifade etmek için God Class (Tanrı sınıf) terimi kullanılır.

Bir sınıfta çok fazla metodunuz varsa kodun akışı esnasında sınıfın davranışını değiştirmek için o sınıfa kaç kere girmek zorunda olduğunuzu düşünün. Bu durum, Açık-Kapalı prensibine (Open-closed principle) -yani gelişime açık, değişime kapalı ilkesi- aykırı olabilir.

5. Üçüncü parti kütüphanelerin LTS/stabil sürümlerini kullanın

Her zaman sizden sonra kodunuzu kullanacak ve projenizi yeniden derleyecek kişiyi düşünün. Kütüphanelerin LTS (Long Term Support / Uzun Süreli Destek) sürümlerini kullanmak yeni özelliklere sahip olma açısından iyi bir tercih olmasa da gelecekte re-build / re-compile ihtiyaçlarını düşününce daha iyidir.

Kullandığınız araçların en yeni ve en güzel sürümlerini kullanma isteğinizi bastırın. Her zaman en güvenli ve en stabil sürüme bağlı olun. Gelecekteki kendiniz ve iş arkadaşlarınız size teşekkür edecek!

6. En yaygın tasarım desenlerini tanımlamayı öğrenin

Çoğu büyük projenin bir veya birden fazla tasarım deseni kullanılarak yapıldığı doğrudur. Tasarım desenleri elemanların açıklamalarını, ilişkilerini ve soyutlama seviyelerini (abstraction level) tanımlar. Hepsini bilmek veya hepsinde iyi olmak zorunda değilsiniz fakat en temel olanları bilmek faydalı olacaktır. Yalnızca düşünme ve tasarlama açısından değil, aynı zamanda code base için tespit etmek açısından da.

Code base içinde tasarım desenlerini tanımlayabilen kişi, belirli sınıf ve objeler için nereye bakması gerektiğini bildiği için kodu sürdürebilir ve ekstra fonksiyonlar ekleyebilir.

İyi uygulanmış bir tasarım deseni, projeye dahil olan herkesin aynı tasarım dilini konuşmasını ve kod içinde daha etkili iletişim kurmasını sağlar.

7. Her zaman kendinizden sonrakini düşünün

Bu kişi siz olabilirsiniz, bir iş arkadaşınız olabilir, yeni bir çalışan olabilir, hatta başka bir şirkette çalışan bir yazılımcı da olabilir, ama birileri sizin kodunuzu sürdürmek veya ekstra fonksiyonlar eklemek zorunda kalacaktır.

Çoğu junior yazılımcı, yalnızca bir kişinin kod yazdığı ve başka kimsenin dahil olmadığı klasik üniversite projesi yaklaşımının olduğu projelerde kullanıldığı için bu maddenin anlaşılması biraz zor.

Profesyonel bir ortamda durum biraz daha farklı; yıllar önce yazılmış bir projede kod yazmanız istenecek ve kodunuzun birkaç yıl içinde gelecek “sonraki kişi” için hazır olması gerekecek. Yani bir şeyin çalışır hale gelmesi için geçici bir kod yazdığınızda, build sürecinde eklediğiniz şeyi dokümante etmekten kaçındığınızda, refactoring etmekten imtina ettiğinizde, ileride sizden sonra uğraşacak kişi için teknik borç (technical debt) çıkarıyorsunuz.

Birkaç saatte bir kodunuzu gözden geçirmek için zaman ayırın. README dosyalarına gerekli dokümantasyonu ekleyin, projeye geçici olarak eklediğiniz dosyaları ve kullanılmayan kodları silin. Mimari veya programlama ile ilgili bir konuda karar almanız gerektiğinde zorlanıyorsanız çalışma ortamınızda sizden daha tecrübeli biriyle iletişim kurun. Yalnızca kodunuzun durumunu iyileştirmiş olmayacaksınız, aynı zamanda gelecekte benzer durumların içinde bulunduğunuzda bununla başa çıkmak konusunda kendinizi geliştirmiş olacaksınız ve gururunuzun incinmesine alışacaksınız. (Bu, Junior aşamasını geçtikten sonra sürekli yaşayayacağınız bir şey :) )

Sonuç

Junior seviyesinden mid-level seviyesine geçmek bir gecede olan bir şey değil. Kariyerinizde ilerlemek ve daha iyi bir profesyonel yazılımcı olmak iyi alışkanlıklar edinme işidir. Bu makalede bu geçişe başlamak isteyenler ve Yazılım Geliştirici olarak etki bırakmak isteyenler için en önemli alışkanlıkları sıraladım.

Hyperledger Nedir?

Fri, 05 Apr 2019 12:50:19 +0000

Bilişim veya finans dünyasındaki gelişmeleri az çok takip ediyorsanız blockchain(blokzincir) ve kripto para terimlerini duymuşsunuzdur. Bu yazıda blockhain alanında ses getiren projelerden biri olan Hyperledger’dan bahsedeceğim. Blockchain’i daha önce duymadıysanız ve hakkında bir şeyler öğrenmek isterseniz sayın Mert Susur’un Youtube’da bulunan webinarını izleyebilirsiniz.

Blockchain kelimesini duyduğumuzda aklımıza ilk olarak Bitcoin, Ethereum, Ripple, gibi projeler gelse de blockchainin kullanım alanı yalnızca kripto paralar değildir. Kullanım alanını genişleten projelerden biri de adını gün geçtikçe daha sık duyduğumuz/duyacağımız Hyperledger. 2015 Aralık ayında Linux Foundation tarafından duyurulan ve 2016 yılında çıkan Hyperledger, açık kaynak kodlu bir blockchain projesidir. Amaçları, kısaca, iş dünyasında şirket seviyesindeki işlemlerin idare edileceği blockchain framework’leri geliştirmek; bu işlemler için hem ticari hem de teknik yönetimler tarafından desteklenen tarafsız, açık ve tamamen topluluk odaklı altyapılar sağlamak; insanları blockchain fırsatları konusunda eğitmek ve bu projeleri geliştirecek teknik topluluklar kurmak. Yani Hyperledger adını verdiğimiz proje kesinlikle bir kripto para değil. Hatta projenin bir yetkilisi olan Brian Behlendorf kendisine kripto paralar hakkında sorulan bir soruya karşılık olarak gelecekte asla Hyperledger coin gibi bir proje olmayacağını, global bir para birimi projesinin olası siyasi zorluklarından kaçındıklarını söyleyerek bu konuya açıklık getirmiştir.

Şu anda Hyperledger çatısı altında 12 proje bulunmaktadır. Bu projeler aşağıdaki gibidir:

Burrow
Fabric
Grid
Indy
Iroha
Sawtooth
Caliper
Cello
Composer
Explorer
Quilt
Ursa

Bu projelerden ilk altısı framework, diğer altısı ise tool başlığı altında listelenmektedir.

Hyperledger üyeleri arasında American Express, Cisco, J.P.Morgan, Intel, IBM, SAP, Digicert, FedEx, Huawei, Oracle gibi devler bulunmaktadır. Tam listeye ulaşmak için tıklayın.

Örnek Projeler

Hyperledger ile yapılmış birçok projeye ulaşmak mümkün fakat ben bu yazıda yalnızca üç tanesinden bahsedeceğim.

IBM Food Trust: Gıdaların ilk oluştuğu yerden itibaren masaya gelene kadar geçirdiği tüm süreçleri kayıt altına alarak şeffaflığını ve güvenilirliğini artırmayı hedefleyen bir proje. Food Trust, gıda tedarik zincirindeki tüm aktörlerin değiştirilemez bir veritabanı olarak işlev gören blockchain üzerinde tutulması fikrinin en başarılı örneğidir. Pilot uygulaması Nestlé, Wal-Mart, Tyson Foods ve Golden State Foods ile yapılmaktadır. Proje hakkında ayrıntılı bilgileri yazının sonunda bulabilirsiniz.
Chain-m: NIIT Technologies tarafından geliştirilen Chain-m projesi havayolu şirketlerinin biletleme süreçlerinin blockchain üzerinde sürdürüldüğü bir proje. Hyperledger Fabric kullanılarak yapılan bu projede kullanıcıların web tabanlı bir arayüz üzerinden bu süreçlerin kaydını ve takibini şeffaf bir şekilde yapmaları amaçlanıyor. Proje hakkında ayrıntılı bilgileri yazının sonunda bulabilirsiniz.
ScanTrust: Organik kahve satıcısı Cambio Coffe’nin geliştirdiği bu projede kahve çekirdeğinin tüm yolculuğu blockchain üzerine kaydediliyor.

Kullanıcılar, paketlerin üzerinde yer alan barkodları kullanarak bu yolculuğu görüntüleyebiliyor. Sawtooth ile geliştirilen bu proje hakkındaki ayrıntılı bilgiyi yazının sonunda bulabilirsiniz.

Neden Hyperledger?

Kimlik Doğrulaması: Kripto para projelerinde çok vurgu yapılan konulardan biri kullanıcıların sistem içinde anonim olması. Fakat bu her zaman gerekli değildir. Bu durumlarda Hyperledger tercih sebebi olabilir. Çünkü Hyperledger, permissioned bir blockchaindir ve identity management modülü ile kimlik doğrulaması konusunda bize yardımcı oluyor.
Veri Gizliliği: Bazı projelerde verilerin herkese açık bir ağ üzerinde tutulması ve herkesin erişimine açık olması problemler yaratabilir. Bu sebeple Hyperledger kullanarak belirli bir kullanıcı grubuna özel bazı bilgileri saklayabilirsiniz.
Modüler Mimari: Hyperledger’ın modüler mimarisi, geliştiricilerin ihtiyacı olan veya kullanmak istediği modülleri kullanmasına imkan sağlıyor. Örneğin halihazırda kimlik doğrulaması olan bir şirket, projesinin içine kendi kimlik doğrulamasını ekleyebilir.
Dil Seçenekleri: Hyperledger Java, Go ve NodeJS ile geliştirme yapmamıza imkan veriyor.
Ücretsiz: İşlem yapmak için veya blockchain üzerine bir veri tutmak için para ödemenize gerek yoktur.
Hız: Public blockchainler, ölçeklenebilirlik problemi sebebiyle yaşanan hız sorunları yüzünden iş dünyasında pek tercih edilmiyor. Bu noktada devreye Hyperledger ve diğer permissioned blockchain’ler giriyor.
Consensus algoritması: Hyperledger’ın consensus algoritmasının POW kadar güvenli olduğu düşünülmüyor. Buna karşın herkesin kimliğinin bilindiği bir blockchain’de POW gibi yüksek enerji gerektiren bir algoritmaya gerek olmadığı görüşü de var.

Temel Terimler

Chaincode: Ethereum’dan aşina olduğumuz smart contract’ların Hyperledger’daki adı chaincode’dur.
Channel: Channel’lar alt ağlar oluşturmak için kullanılır. Alt ağlar yalnızca belirli kullanıcıların bağlandığı yerlerdir. Böylece belirli kullanıcı grupları gizliliklerini sağlarlar. Her channel’ın kendi ledger’ı vardır ve o channel içinde yapılan tüm transaction’ları channel üyeleri görebilir.
Ledger: Yalnızca sondan veri eklemeye izin veren kayıt defteri.
World State: Ağdaki tüm objelerin anlık durumları.
Identity: Ağa katılan tüm kişilerin eşsiz tanımlayacıları.

Yazıda Bahsedilen Linkler

Yararlanılan Kaynaklar

Visual Studio Code Eklenti Tavsiyeleri

Thu, 31 Jan 2019 12:46:42 +0000

Bu yazı Ocak 2019’da yazılmıştır. Geçen sürede güncelliğini kaybetmiş olabilir. Okurken bunu göz önünde bulundurmanızı tavsiye ederim.

Merhabalar. Bu yazımda kendim kullanıp faydasını gördüğüm VSCode eklentilerinden bahsedeceğim. Daha önce Brackets, Atom, Sublime editörlerini kısa süreli kullandım ve en sonunda Visual Studio Code kullanmaya karar verdim. Aslında kullandığım diğer editörler de güzeldi fakat ben en çok Visual Studio Code’u beğendim ve uzun süredir yalnızca bunu kullanıyorum. Hemen eklentilere geçelim.

Auto Close Tag

Html etiketlerinin otomatik olarak kapanması için kullandığım eklenti. Herhangi bir ayar vs. gerekmiyor.

Duplicate selection or line

Adından da anlaşılacağı üzere seçili olan bir metni veya satırı kopyalar. Ctrl+d kısayolunu kullandığınızda eğer seçili olan metin varsa onu, yoksa o satırı kopyalar.

Live Server

Yaptığınız çalışmaları test etmek için local server kurar. Aynı zamanda editör üzerinden değişiklik yapıp kaydettiğinizde sayfayı günceller. Çalıştırmak için herhangi bir ayar yapmanız gerekmiyor. En kolay çalıştırma şekli Alt + L + O kısayoludur. Bunun dışında editörün alt kısmında bulunan status bar’da bulunan Go Live butonunu kullanabilirsiniz. Son olarak Ctrl + Shift +P kısayoluyla commands penceresini açıp Live Server yazıp çıkan listeden Open with Live Server seçeneğiyle de kullanabilirsiniz.

Polacode

Eğer yazılımla alakalı blog tutuyorsanız veya yazdığınız kodları resim olarak kaydetmek istiyorsanız Polacode bu konuda size yardımcı oluyor. Eğer http://carbon.now.sh/ kullandıysanız aşinasınızdır. Kullanımı da oldukça basit. Ctrl + Shift + P ile commands penceresini açın ve Polacode yazın. Ekran ikiye bölünecektir. Polacode sekmesine kodunuzu yapıştırın ve aşağıda bulunan butona tıklayın.

Vetur

Bu eklenti yalnızca VueJS kullananların ilgisini çekecek bir eklenti. Kod tamamlama, syntax renklendirme, hata kontrolü, hazır kodlar, emmet gibi birçok eklentiyi içinde barındırıyor.

Image Preview

Kodlarınızda bulunan resim dosyalarına ait path’lerin üzerine geldiğinizde küçük bir önizleme gösteriyor.

Path Intellisense

Adından da tahmin edileceği üzere path’lerinizi otomatik olarak tamamlar.

Prettier — Code formatter

Bu yazıyı yazdığım sırada 6.3 milyon indirmesi olan bir eklenti. Yazdığınız kodu görsel olarak düzeltiyor. Ekstra bir ayar vs. gerekmiyor. Ctrl + Shift + P ile commands penceresini açın ve “Format document” yazın. İsterseniz tüm metni, isterseniz de sadece seçili olan bir kısmı düzeltebilirsiniz.

Code Runner

Yazdığınız bir kod parçacığının çıktısını hızlıca konsoldan görmenize yarar. Sadece çalıştırmak istediğiniz kısmı seçin ve sağ tıklayın, Run Code’a tıkladığınızda konsoldan çıktı görünecektir. Alternatif olarak Ctrl + Alt + N kısayolu da kullanılabilir. Desteklemediği dil yok denebilir.

Faker (vscode-faker)

Aralarında en sevdiğim eklentilerden biri. Fake isim, adres, tarih, şirket ismi, resim gibi şeyler üretiyor. Yalnızca Ctrl + Shift + P yazıp faker yazın ve istediğiniz örnek datayı seçin.

OOP’nin 4 Ana Prensibi: Encapsulation, Inheritence, Abstraction, Polymorphism

Thu, 10 Jan 2019 11:59:24 +0000

İyi bir kod tasarımı için uyulması gereken bazı prensipler vardır. Prensipler zorunlu değildir fakat uyulduğunda hem dünya çapında standart bir kod yazmış oluruz hem de sürdürülebilirliği yüksek bir iş ortaya çıkar. Aslında herhangi bir programlama dilinde az da olsa bir geçmişiniz varsa bu prensipleri muhtemelen kullanıyorsunuzdur fakat adlarını bilmiyorsunuzdur. Öğrenmesi ve uygulaması çok kolay olan bu prensipler özellikle Junior yazılımcılar tarafından korkuyla yaklaşılan şeyler. Hadi bu prensipleri ve amaçlarını inceleyelim.

Encapsulation (Kapsülleme)

Türkçe’de kapsülleme veya sarmalama olarak bilinen encapsulation prensibi class’ın property’lerini korumaya almasıdır. Bu korumayı sağlamak için private ve protected access modifier’larını (erişim belirteci) kullanırız. Eğer bir property’i tanımlarken private kullanırsak o class dışında hiçbir yerden erişim sağlanamaz. Protected kullanırsak da yalnızca subclass’lar ve aynı package’da bulunan classlar tarafından erişilir. Encapsulation prensibinin maksadı class’a ait property’lere her classın istediği gibi erişmesini ve değiştirmesini engellemektir. Erişim kısıtlanmayacaksa bile erişimi getter/setter methodları gibi yöntemlerle kontrol altına almaktır. Zaten encapsulation prensibine gözümüzün en aşina olduğu yer getter/setter methodlarıdır. Bu prensiple alakalı biri getter/setter methodları olmak üzere iki örnek vereceğim.

public class Personel {

    private Long personelNu;
    private String isim;
    private String soyisim;
    private String departman;

    public Long getPersonelNu() {
	return personelNu;
    }

    public void setPersonelNu(Long personelNu) {
	this.personelNu = personelNu;
    }

    public String getIsim() {
	return isim;
    }

    public void setIsim(String isim) {
	this.isim = isim;
    }

    public String getSoyisim() {
	return soyisim;
    }

    public void setSoyisim(String soyisim) {
	this.soyisim = soyisim;
    }

    public String getDepartman() {
	return departman;
    }

    public void setDepartman(String departman) {
	this.departman = departman;
    }
}

Yukarıdaki örnekte gördüğünüz gibi hiçbir classın Personel property’lerine doğrudan erişim hakkı yoktur. Erişimi yalnızca getter/setter methodlarıyla yapabilirler. Tahmin edileceği gibi getter/setter methodları private olamaz.

public class Sayac {

    private Integer sayac;

    public Sayac() {
	sayac = 1;
    }

    public Integer sayacArtir(){
	return sayac++;
    }

    public Integer getSayac() {
	return sayac;
    }
}

Yukarıda ise örnek bir Sayac classı bulunmakta. Diğer class’lar erişim sağlanmak istediğinde getter methodunu, sayacı artırmak istediğinde ise sayacArtir() methodunu kullanmak zorunda. Yani herhangi bir class’ın ornekSayac.sayac += 1 gibi bir şey yazmaya yetkisi yok. Çünkü eğer herhangi bir class bunu yazabilirse sayacı istediği gibi manipüle edebilir. Bu sebeple encapsulation’ı kullanarak Sayac’ın property’sini korumaya almış oluyoruz.

Inheritence (Kalıtım)

Adından tahmin edilebileceği üzere herhangi bir class’ın üst class’larına ait olan method ve propertyleri kalıtım yoluyla almasıdır. Günlük hayattan bir örnekle anlaması çok daha kolay. Telefon adında bir class düşünelim. Bu class tüm telefonlarda ortak olan bazı property’leri ve method’ları barındıracak. aramaYap(); mesajGonder(); methodları ve imeiNumber property’sini örnek verebiliriz. Bu class’ın tüm alt class’ları bu methodları ve property’leri kullanabilecektir. Böylece AkilliTelefon ve TusluTelefon classlarını tanımlarken kalıtım yoluyla alınan bu property’leri ve method’ları tekrar tanımlamak zorunda kalmayacağız.

Aşağıda örnek bir Telefon class’ı bulunmakta.

public class Telefon {

    protected String imeiNumber;

    protected void aramaYap(){
	System.out.println("Arama yapıldı.");
    }

    protected void mesajGonder(){
	System.out.println("Mesaj gönderildi.");
    }

    public String getImeiNumber() {
	return imeiNumber;
    }

    public void setImeiNumber(String imeiNumber) {
	this.imeiNumber = imeiNumber;
    }
}

Şimdi de bu class’ın iki subclass’ını tanımlayalım.

public class AkilliTelefon extends Telefon {

    protected void interneteBaglan() {
	System.out.println("İnternete bağlandı.");
    }
}

public class TusluTelefon extends Telefon {

    protected void yilanOyununuAc(){
	System.out.println("Yılan oyunu açıldı.");
    }
}

Şimdi de Test class’ını yazalım.

public class Test {

    public static void main(String[] args) {

	AkilliTelefon akilliTelefon = new AkilliTelefon();
	akilliTelefon.setImeiNumber("354816220461203");
	akilliTelefon.aramaYap();
	akilliTelefon.interneteBaglan();

	TusluTelefon tusluTelefon = new TusluTelefon();
	tusluTelefon.setImeiNumber("354816221162234");
	tusluTelefon.mesajGonder();
	tusluTelefon.yilanOyununuAc();
    }

}

Yukarıdaki örnekte görüldü üzere AkilliTelefon ve TusluTelefon class’larının instance’ları hem Telefon class’ına ait olan aramaYap() ve mesajGonder() methodlarını ve imeiNumber property’sini inheritence (kalıtım) yoluyla alıp kullanıyor hem de kendi class’larına ait olan interneteBaglan() ve yilanOyunuAc() methodlarını kullanıyor.

Abstraction (Soyutlama)

Bu prensibe doğrudan bir örnekle başlıyoruz. Aşağıdaki kod parçacığının ne yaptığını, ne işe yaradığını biliyor musunuz? Biraz incelerseniz ne iş yaptığını tahmin edeceksiniz ama buna hiç gerek yok. Ben değil, abstraction prensibi söylüyor bunu. Aşağıdaki kod parçacığı IDE’nizi her açtığınızda en az bir kere kullandığınız System.out.println(); methodunun arkaplanda yaptığı işlerin bir kısmı. Fakat siz System.out.println(); yazarken arka planda neler döndüğünü bilmeden yazıyorsunuz. Bunun sebebi abstraction prensibi. Daha derli toplu bir ifadeyle objelerin ayrıntılarıyla uğraşmak yerine yalnızca girdi ve çıktılarına odaklanarak tasarımı daha iyi oluşturmayı ve anlamayı sağlamaktır.

try {
      synchronized (this) {
	  ensureOpen();
	  textOut.write(s);
	  textOut.flushBuffer();
	  charOut.flushBuffer();
	  if (autoFlush && (s.indexOf('\n') >= 0))
	      out.flush();
    }
}
catch (InterruptedIOException x) {
    Thread.currentThread().interrupt();
}
catch (IOException x) {
    trouble = true;
}

Bu prensibe araba kullanmak örneği de verilebilir. Araba kullanan birinin gaz pedalına ve frene bastığında veya vites değiştirdiğinde neler olduğunu bilmesine gerek yok. Yalnızca girdi ve çıktıları öğrenerek rahatça araba kullanabilir.

Polymorphism (Çok Biçimlilik)

Polymorphism, (çok biçimlilik) methodların objeye göre farklı çıktılar üretmesi veya farklı işler yapmasıdır. Yani alışageldiğimiz gibi methodlara sabit görevler vermek yerine onlara çok biçimli (polimorf) davranacak şekilde bir esneklik vermektir.

Polymorphism Örnek 1 (Method Overriding)

İlk vereceğim örnek klişe ama -bence- konuyu en iyi anlatan örnek.

public class Hayvan {

    public void sesCikar(){

	System.out.println("Hayvan sesi.");
    }
}

public class Kedi extends Hayvan {

    @Override
    public void sesCikar() {
	System.out.println("Miyav");
    }
}

public class Kopek extends Hayvan {

    @Override
    public void sesCikar() {
	System.out.println("Hav Hav");
    }
}

Yukarıda Hayvan class’ı ve Kedi — Kopek subclass’ları var. Hayvan class’ının sesCikar metodu olmasına rağmen Kedi ve Kopek subclass’ları için özel sesCikar metodu tanımladık. Aşağıda ise Hayvan tipindeki değişkene Kedi instance’ı verince kedi sesi, Kopek instance’ı verince köpek sesi çıkaracak.

public class Test {

    public static void main(String[] args) {

	Hayvan hayvan = new Hayvan();
	hayvan.sesCikar();

	System.out.println("-------");

	hayvan = new Kedi();
	hayvan.sesCikar();

	System.out.println("-------");

	hayvan = new Kopek();
	hayvan.sesCikar();

    }
}

Yukarıdaki testin çıktısı aşağıdaki gibi olacaktır.

Hayvan sesi.
— — — –
Miyav
— — –
Hav Hav

Polymorphism Örnek 2 (Method Overloading)

Bu örnekte ise aynı isimde iki method var. Bu iki method’un biri iki Integer değeri alıyor, diğeri ise bir Integer değeri alıyor. Biz kaç parametre göndererek çağırırsak o method çalışacaktır.

public void yemekYe(Integer hamburgerSayisi, Integer kolaSayisi){
      System.out.println(((hamburgerSayisi*261)+(kolaSayisi*168)) + " kalori alındı.");
  }

  public void yemekYe(Integer hamburgerSayisi){
      System.out.println((hamburgerSayisi*261)+ " kalori alındı.");
  }

  public void test() {

      yemekYe(2, 1);
      yemekYe(2);

}

Spring Initialzr ile Proje Oluşturma

Fri, 06 Jul 2018 11:47:32 +0000

Merhaba, bu yazıda Spring Initializr kullanarak basit bir HelloWorld projesi yapmayı anlatacağım. Spring Initialzr, istediğimiz gerekliliklere göre bize temel konfigürasyonları hazır bir Spring projesi üretip veren bir araçtır. Benim bildiğim 3 farklı kullanım şekli var:

http://start.spring.io/ adresinden indirerek.
IDE Pluginleri ile
Spring CLI kullanarak.

Ben bu yazıda doğrudan internet sitesi üzerinden anlatacağım. Öncelikle yukarıda verdiğim Spring Initialzr linkine tıklayın.

Bu sayfada proje adını, Spring ve Java sürümlerini, Maven/Gradle tercihini ve gereklilikleri seçiyoruz. Ben yalnızca Web gerekliliğini seçip bir proje oluşturuyorum. Tüm gereklilikleri girip Generate Project’e tıklayıp projeyi indirdikten sonra arşivden çıkarın. Sonra (Eclipse için) Project Explorer kısmından Import seçeneğine tıklayıp açılan menüde Existing Maven Project’i seçin ve arşivden çıkardığınız projeyi Import edin.

Finish seçeneğine tıkladıktan sonra ortalama 3–5 saniye projeyi gerekliliklerini indirmesi sürüyor. Projenin son hali aşağıdaki gibi oluyor.

Bu proje yapısını biraz inceleyelim.

Spring Elements kısmında Spring’e ait olan Bean, Controller, Repository gibi bileşenlerin kopyası bulunuyor.
src/main/java kısmında java classlarımız bulunuyor.
src/main/resources application.properties dosyasının bulunduğu dizin. Aynı zamanda html, css dosyalarımızı da burada tutuyoruz.
src/test/java kısmı test için kullanılıyor.
Altında JRE ve Maven bağımlılıkları bulunuyor.

Projemiz bu haliyle çalışmaya hazır. Sağ tıklayıp Run As > Spring Boot App diyerek çalıştırabiliriz.

Çalıştırdığımızda Console’da buna benzer bir çıktı alacaksınız. Burada aşama aşama neler yaptığını yazıyor. Şimdilik burada yazanlar bizim için önemsiz fakat ileride kullanacağız. Şimdilik önemli olan kısım “Started HelloWorldApplication in …” yazan kısım ve “Tomcat started on port(s): 8080 (http)…” yazan kısım. Uygulamamızın default port olan 8080 portunda başarılı bir şekilde çalıştırıldığını buradan görüyoruz. Henüz isteklerimize cevap verecek bir bileşen olmadığından dolayı localhost:8080 adresine gittiğinizde error sayfası ile karşılaşacaksınız. Son olarak bir Hello World çıktısı alıp bu yazıyı bitirelim.

src/main/java kısmına gelin ve HelloWorld paketinin altında yeni bir paket oluşturun. Ben adını com.kamer.helloworld.controllers olarak veriyorum. Burada önemli bir noktaya değinmekte fayda var. Siz projeyi çalıştırdığınızda Spring, Controller, Repository, RestController gibi bileşenleri taramak için main method’un bulunduğu paketin altındaki paketleri tarayacak. Bu yüzden eğer oluşturacağınız herhangi bir component bu paketin alt katmanlarından birinde olmazsa hata alırsınız. Spring’e başka bir yeri taraması için bir ayar yapabiliriz fakat şimdilik bu şekilde devam ediyorum.

Sonra bu paketin içinde HelloController adında bir sınıf yaratıp sınıfın hemen üstüne @RestController anotasyonunu ekleyin. Sonra aşağıdaki gibi bir method oluşturun.

Yukarıda yaptığımız işlemi açıklayayım. Öncelikle anotasyonlar Spring Framework ile iletişim kurma şeklimiz. Yani bazı şeyleri Spring’e söyleyip ondan sonra kalan şeyleri serinin ilk yazısında açıkladığım IoC prensibine bırakıyoruz. Öncelikle bu sınıfın RestController olduğunu, yani yapılan HTTP isteklerine cevap verecek bir controller olduğunu söyledik. Altındaki method’da ise ilk restful endpoint’imizi yarattık. GET isteklerine cevap vereceğini, “/” dizinine gelecek istekleri dinleyeceğini söyledik. Biz uygulamamızı çalıştırdığımızda Spring öncelikle bu anotasyonları okuyacak, eğer biz aksi bir şey söylemezsek Main metodun bulunduğu paketin altındaki her yere bakıp bunları ‘map’leyecek. Ondan sonra gelen isteklere bizim istediğimiz şekilde cevap verilmesini sağlayacak. Bu sınıfı yazdıktan sonra Relaunch yaparak uygulamamızı tekrar çalıştırıyoruz. Bu sefer konsolda farklı bir şey yazıyor.

Burada paketleri tararken bizim yazdığımız @RequestMapping anotasyonunu gördüğünü, home() methodunu çalıştırmak için “/” dizinine gelecek bir GET isteği beklediğini bize söylüyor. Bu aşamadan sonra ister Postman gibi bir programla, ister curl ile, isterseniz de tarayıcınızla localhost:8080 adresine GET isteği göndererek Hello World! çıktısını görebilirsiniz.

İngilizce Öğrenme Üzerine Tavsiyeler

Sat, 30 Jun 2018 21:56:04 +0000

Aşağıda sıraladığım tavsiyeler yalnızca kendi tecrübelerimdir.

İnternette tonlarca set, yöntem, iddia vs. var. Bunların hemen hemen çoğundan uzak durmanız gerekiyor. Aklıma gelenlerden bahsedeyim:
- Uyurken İngilizce: Bu iddia safsatadır. Bilimsel bir açıklaması yoktur. Aldous Huxley’in Cesur Yeni Dünya kitabından esinlenilmiştir. Günümüz teknolojisinde kimse size uykuda İngilizce öğretemez.
- X Günde İngilizce: Eğer maksadınız İngilizce öğrenmekse bundan da uzak durmalısınız. Zira çevrenize bakarsanız saçma sapan dil kursları bu işi iyice abarttı ve gün konusunda birbirleriyle yarışan reklamlar yapıyorlar. 15 günde, 30 günde dil öğrenilmez. Bu kursta size ezberletecekleri cümle kalıplarını 5 TL’ye alacağınız bir konuşma kılavuzuyla da yaparsınız zaten.
- “Yeni bir teknik buldum, mükemmel” diyenlerin bir kısmı — Daha web sayfalarında ne Türkçe’yi ne de İngilizce’yi doğru düzgün ifade edemeyen kimseler ilginç iddialarla safsatalarını sunuyorlar. Kendi kitapları, yöntemleri vs. var. Sonuçta sizden yine bir ton para alıp karşılığında hüsran veriyorlar. (Aralarında muhakkak ki iyileri vardır ama bir kısmı maalesef böyle)
- Konuşma kılavuzları: Maksadınız İngilizce öğrenmekse hiç bulaşmayın. Sizin için yalnızca zaman kaybıdır. Ama seyahat için kullanacaksanız ve acil bir şeyler lazımsa elbette güzel bir çözümdür.
Dile Maruz Kalmak: Bu kavram dil öğrenimi açısından önemlidir. İlk tercih tabi ki öğrendiğiniz dilin konuşulduğu ülkeye gitmektir fakat böyle bir imkân yoksa çevrenizde bu ortamı yaratmanız gerekiyor. Bu, kullandığınız telefondan tutun da izlediğiniz filmlere, okuduğunuz kitaplara ya da dinlediğiniz şeylere kadar her şeyin mümkün olduğunda sizi dil konusunda sizi desteklemesi demektir.
Hikaye Kitapları: Seviyeniz A1 de olsa B2 de olsa İngilizce okuyun. Düşük seviyelerde olanlar için kitapçılarda “stage kitapları” olarak geçen kitapları almak çooook faydalıdır. Zorlansanız bile okumaya çabalarsanız ve bu okumaları da gelişiminizle orantılı olarak artırırsanız faydasını göreceksiniz. Bununla alakalı olarak Türk yayınevlerinden çıkan kitapları tavsiye etmiyorum. Sadeleştirilirken veya çevrilirken özenilmediği için içeriği yanıltıcı olabiliyor. Oxford Press gibi yayınlar da pahalı oluyor ama ikinci el kitapçılarda (Ankara’da Adilhan’da, İstanbul’da Akmar’da mesela) 3–4 TL’ye bulunuyor.
Dinleme ve Konuşma: Eğer yalnızca kitaptan çalışıyorsanız muhtemelen bu iki becerinizde problem vardır. Ama dili yalnızca okuyarak ve yazarak kullanmayacağınız için bu becerilerinizi de başlangıç seviyelerinden itibaren dile maruz kalma sürecine dahil ederek geliştirmeniz gerekmektedir. Çünkü telaffuzunuzda bir eksiklik varsa o dili tekrar öğreniyor gibi olursunuz. Öğrenecekseniz bir kere öğrenin.
Kelime Öğrenimi: Bununla alakalı son zamanlarda popüler olan birçok uygulama/site var. Deneme şansı bulduklarım arasında en beğendiğim memrise oldu. Ama arada bir aklınıza geldikçe bakıyorsanız çok faydalı bir seçenek değil. Şahsen ben bu programlarda devamlılık sağlayamadığım için kullanmadım. Kelime ile bildiğim birçok şeyi çeviriye borçluyum. Çeviri derken kastım kendi kendinize çeviri yapmanız. Okuduğunuz bir öyküyü, izlediğiniz programdan bir repliği, tabelaları, film afişlerini, aklınıza gelebilecek her şeyi çevirin. Çünkü bunları yapmak için ihtiyaç duyacağınız en önemli şey kelime. (Bunu kendi kendinize oynadığınız bir oyun gibi düşünebilirsiniz.)
Mektup arkadaşı, Skype arkadaşı: Dile maruz kalma etmenlerinden biri olarak kabul edebiliriz bunu. Sandığınızdan daha iyi sonuçlar alabileceğiniz bir yöntemdir. Eskiden omegle gibi bir seçenek vardı bunun için ama artık amacından sapmış bir site konumunda. Bunun için önereceğim ilk site https://howdoyou.do/ Bunun dışında penpal gibi sitelerden de faydalanabilir, basit bir Google araştırmasıyla güzel siteler bulabilirsiniz.
Yazın: Akılda kalmaz satırda kalır sözünün doğruluğuna inananlardanım. Bu yüzden mutlaka defterleriniz olsun. Bu sadece not tutmakla sınırlı değil. Günlük, köşe yazarı gibi en az 200–300 kelime yazın. Bu, dil kullanımına aşina olmak için çok güzel bir yöntem.
Kelime Kartları: Kelime kartı hazırlamak çok basit ve etkilidir. Excel’den hazırlayacağınız bir tabloyu, karton kağıda çıktı almak bu işlem için yeterlidir. Diğer bir seçenek ise 16. maddede bahsettiğim web sitelerinden biri olan Quizlet.
Partner: İngilizce öğrenen bir arkadaşınızın olması ve İngilizce konusunda paslaşmanız ikiniz için de faydalı. İkinizin de hangi seviyede olduğunun önemi yok. Yalnızca ortak bir birikim oluşturmak ve biri bıraktığında diğerinin motive edebilmesi için.
Utangaç olmayın: Konuşurken İngilizler gibi “errr…” yaptığınızca veya ağzınızı açarak telaffuz etmeye çalıştığınızda komik olmuyorsunuz. Bu yüzden konuşmaktan ve doğru telaffuz etmekten korkmayın. İstanbul gibi bir şehirde yaşıyorsanız turistler bu konuda çok iyi bir avantajdır. Ama sakın gidip de hiçbir turiste “Hello! Sorry for my bad English. I’m learning English. I want to practice.” demeyin. Ya sizi umursamayacaktır ya da İngilizce’yi iyi bilmediğinizi bildiği için doğallıktan uzaklaşacaktır. Bunun yerine adres sorun, tişörtünün çok şık olduğunu falan söyleyin.
Sözlük: Türkçe sözlükleri mümkün olduğunda az kullanmaya çalışın. İngilizce-İngilizce sözlük kullanmak daha faydalı olur.
Dizi/Film izleyin: Altyazılı dizi/film izlemek dinleme yapmak açısından faydalıdır fakat izlediğiniz 5 sezon dizide karakterlerin hiç yüzünü görmediyseniz yanlış yapıyorsunuz demektir. Dizi izleyip dinlemeye çalışın, sadece okumayın. Aksi takdirde pek bir faydası olmuyor.
Telaffuz-Ağız Şekilleri: Telaffuz konusunda ilk tavsiyem şu: eğer native-like bir telaffuzu ve konuşmayı hedefliyorsanız yabancı dizileri ve filmleri izlerken konuşanların ağızlarına bakın. Zira İngilizce konuşurken ağzınızın şekli doğru değilse native-like bir konuşma elde edemezsiniz. Ağız şekillerinden kastım ise harfler ağızdan çıkarken ağzın aldığı şekiller. En bariz örneğini “e” harfinde görürsünüz zaten.
Telaffuz-Altyazı: Dizi ve filmleri internetten indirip İngilizce altyazıyı programla kendiniz ekleyin. Her programda altyazı senkronizesi vardır. Videonun üstünde sağ tıkladığınız zaman altyazı geciktirmesi veya altyazı senkronizesi olarak geçer. Altyazıyı -0.5 saniye yapın ve filmi izlerken altyazıyı sesli okuyun, hatta taklit edin. -0.5 saniyede okursanız sesle hemen hemen eş zamanlı bir seslendirme olacaktır. Bu sayede hatalarınızı daha o saniyede fark edeceksiniz. (Bu işlem için tavsiyem BSPlayer’dır. İzlediğiniz dizi/film ismini BSPlayer veritabanından ve diğer büyük altyazı sitelerinden arar ve otomatik olarak altyazılı açar. Size sadece Türkçe ve İngilizce seçimini yapmak düşer. Hatta ikincil bir altyazı açıp. Altyazı olarak İngilizce, üstyazı olarak Türkçe de yapabilirsiniz.
Telaffuz-Kendinizi dinleyin: Elinize herhangi bir makale, yazı vs. alın ve sesli okurken bunu kaydedin. Sonra kendiniz tekrar bu kaydı dinleyin. Bunu kendi kendinize yapmanızın manası ise şu: günümüzde oyunlar, diziler, filmler aracılığıyla hepimiz İngilizce duymaya aşinayız. Hemen hemen bütün kelimelerin okunuşu bilinçaltınızda var ve sıkıntı bunu pratiğe dökmekte. Bu nedenle kendi yaptığınız ve doğru olduğunu düşündüğünüz kaydı tekrar dinlediğinizde sahip olduğunuz kulak doygunluğu size hatalarınızı gösterecek.
En yaygın kullanılan kelimeler: Okuduğunuz, dinlediğiniz İngilizce’yi anlamak için en çok ihtiyacınız olan şey kelimeler. Bu yüzden belirli seviyede İngilizce birikiminiz olmalı. Bence bunun için en önemi kaynak en çok kullanılan kelimelerdir. Bunun için internette hazır bulunan her kaynağı tavsiye etmiyorum. En çok kullanılan kelimeler dizi-film altyazılarından analiz edilmiş olmalıdır. Ancak böyle doğru sonuçlara ulaşabilir. Birçok dil için bu verilere bu linkten ulaşabilirsiniz.
Kendim kullandığım ve faydalandığım sitelerden aklıma gelenleri de şöyle sıralıyorum:
- https://www.vocabulary.com/ -> Sözlük ve kelime quizi için kullanılabilecek sitenin en önemli işlevi okuduğunuz parçaların kelimelerini sizin yerinize çıkarması. Metin verdiğinizde tüm kelimeleri çıkarıyor ve size bir liste veriyor. Sizin aralarından seçtiklerinizi bir liste olarak anlamlarıyla veriyor ve öğrendiğinizi test etmek için quize girebiliyorsunuz. (Ücretli android uygulaması da var.)
- https://www.voscreen.com/ -> Bunu bir çoğunuz duymuştur muhtemelen. İlk çıktığında tesadüfen görmüştüm, üstüne sürekli bir şeyler katarak ilerleyen enfes bir site. Genellikle filmlerden/dizilerden kesitler sunuluyor ve anlamı soruluyor. Tabii bu kesitler çok kısa. Genellikle 1–2 cümlelik şeyler oluyor.
- https://www.ted.com/ -> Burada yüzlerce konu hakkında, çoğu 50–60 farklı dilde altyazıya sahip, binlerce konuşma videosu var. Ücretsiz mp3 veya mp4 olarak indirme seçeneği ve konuşmanın her dilde yazılı hâlini indirme seçeneği de mevcut.
- https://www.engvid.com/ -> Bu site belirli bir seviyeye gelmiş arkadaşlar için. İngilizce öğretmenleri İngilizce olarak birçok konuyu anlatıyor. Esprili dilleri konuları daha zevkli kılıyor. (James favorim)
- http://lyricstraining.com/ -> Şarkı sözleri ile İngilizce.
- http://www.ozdic.com/ -> Merriam Webster ile kullandığım sözlük. Pek bilinmediği için buradan veriyorum. (Collocation dictionary)
- http://fraze.it/ -> Girdiğiniz kelimeyi cümle içinde kullanımlarıyla gösteriyor.
- https://www.grammarly.com/ -> Yazdığınız cümlenin/metnin grammer incelemesini yapıyor ve size doğrusunu öneriyor. Başarılı bir proje.
- https://quizlet.com/ -> Kelime kartları oluşturmak için kullanılan bir site. Girdiğiniz kelime kartlarına ses ekleme, mobil cihazlardan bu kartlara çalışma, pdf çıktısı alma, oyunlar kullanarak öğrenme veya word, excel gibi kaynaklardan kopyaladığınız 1000’lerce kelimeyi 5 saniyede ekleme gibi özellikleri var.
Youtube Kanalları
- Speak English With Misterduncan
- Luke’s English Podcast
- English With Lucy
- Jade Joddle
- Go Natural English
- Simple English Videos
- podEnglish
Podcastler:
- British Council
- Stuff They Don’t Want You to Know
- Serial
- Rationally Speaking
- Radiolab
- A History Of The World In 100 Object
- In Our Time
- Ted Radio Hour
- Answer Me This
- Spark
- Comedian’s Comedian
- Comedians Telling Stuff
- This American Life
- Stuff You Should Know
- Revisionist History
- Myths and Legends

Spring Framework | IoC Container

Thu, 14 Jun 2018 11:40:12 +0000

IoC ve DI prensiplerini anlattığım bir önceki yazıda IoC’yi interface kullanarak kendimiz yapmayı anlatmıştım.Spring Framework’de ise bu prensip IoC containerlar ile sağlanır. IoC containerların temel görevi beanleri yönetmektir. Yönetmek kelimesinin kapsamı ise geniştir. Beanleri oluşturmak, birbirleriyle uyumunu sağlamak, ayarlarını yapılandırmak, yaşam döngülerini kontrol etmek gibi işler yönetmek kelimesinin kapsamına girer. Bu noktada “bean nedir?” sorusunun da cevabını vermem gerekiyor. Bean standartları belirlenmiş bir Java classıdır. Normal classtan üç farkı vardır:

Tüm değişkenleri private olmak zorunda. (Getter/Setter kullanmanız gerekiyor.)
Parametresiz bir public constructor’ı olmak zorunda.
Serializable interface’ini implemente etmek zorunda.

Yukarıdaki klasik bir IoC Container akış diyagramı var. Diyagram üzerinde çalışma akışı şöyledir:

Container, hazırladığımız POJO classlarını alır. Sonra bu POJO classlarını yönetmek ve konfigüre etmek için xml dosyalarından, anotasyonlardan ve beanlere yönelik hazırlanmış kodlardan gerekli metadatayı alır. Artık elinde hem POJO’lar hem de bu POJO’ları nasıl yöneceğinin bilgisi vardır. Bunun sonucunda IoC, programda kullanıma hazır beanleri yaratır. Bu beanleri yaratırken de IoC prensibini sağlamak için bir önceki yazıda bahsettiğimiz DI prensibini kullanır. Gerekli bağımlılıkları framework tarafındaki aktör olarak kendisi verir.

Spring container’ın ne işe yaradığını öğrendikten sonra irdelemeye devam edelim. İki tip Spring container vardır.

BeanFactory Container
ApplicationContextContainer

BeanFactory Spring Container’a DI desteği sağlayan en temel interface’tir. Beanleri oluşturmanın dışında konfigürasyonlarını yapar ve bağımlılıklarla birbirine bağlar. ApplicationContext’e göre biraz daha ilkel olduğu söylenebilir. Bu sebeple BeanFactory’i kısa kesip ApplicationContext’e geçiyorum.

ApplicationContext ApplicationContext, BeanFactory’nin tüm özelliklerini barındıran ve bunun yanında ekstra yetenekleri olan container’dır. Bu sebeple BeanFactory’e oranla daha çok kullanılıyor. Spring’in kendi dokümanı da bu tercihi destekliyor. Eğer gerçekten kullanmak için iyi bir sebebiniz yoksa ApplicationContext kullanın şeklinde bir ifade geçiyor. Bu sebebe örnek olarak ise kilobayt seviyesinde performans hassasiyeti sağlamanız gereken projeleri örnek verebiliriz. Onun dışında ApplicationContext kullanmak ve sunduğu ekstra özelliklerden faydalanmak daha doğru bir yaklaşım. ApplicationContext’in sunduğu ekstra özellikler bu aşamada biraz daha üst seviye sayılabileceği için bunu konuyu daha sonraki yazılarımdan birine erteleyip ApplicationContext’in farklı kullanım şekillerinden bahsediyorum.

FileSystemXmlApplicationContext

Bu kullanımda ApplicationContext, bean tanımlarını bir xml dosyasından alır. XML dosyası tam dizini ile birlikte constructor’a verilir.

ClassPathXmlApplicationContext

Bu kullanımda ise XML dosyasının tam dizinini vermeye gerek yoktur. XML dosyasının projenin classpath’inde olması yeterlidir.

XmlWebApplicationContext

Bu kullanımda ise tüm beanler web uygulamasının içinde tanımlanır.

İnternette karşılaştığım diğer derslerde ApplicationContext tanımlarını anlatırken getBean() metodu ile beanlerin doğrudan xml konfigürasyonlarına göre elle oluşturulduğunu gördüm. Fakat bunun IoC’ye aykırı olduğunu düşündüğüm için öyle bir girişimde bulunmadım. Gözünüzün veya elinizin yanlış bir şeye alışmasındansa bu kısmın biraz daha soyut kalması daha doğru diye düşünüyorum. Tabii ki tercih ederseniz internette bu örnekleri bulabilirsiniz. Son olarak basit bir bean.xml dosyası göstereceğim.

Yukarıda örnek bir SelamVer class’ı var. Bu classı bean olarak konfigüre etmek istiyorum. Aşağıdaki xml dosyası bunu sağlıyor.

En üstteki dört satır xml, versiyonunu, web-app versiyonunu seçtiğimiz ve kullanacağımız namespace’leri eklediğimiz kısım. Buralar genellikle sabit olur. Aşağıdaki kısımda ise id yazan yerde bean’in adını, class kısmında SelamVer classının yerini verdik. Property kısmında ise örnek olarak selam değişkeninin değerini verdik.

Spring containerlar’la alakalı yazım bu kadar. Yazının başında da söylediğim gibi, anlattığım bu kavramların biraz soyut kalması gayet normal. En azından bir fikriniz olursa somut olarak bir şeyler yapmaya başladığınızda bu bilgilere ihtiyaç duyacaksınız.

Yararlandığım Kaynaklar:

Spring Framework | IoC ve DI

Mon, 11 Jun 2018 11:32:16 +0000

Merhaba. Bu yazıda IoC ve DI olarak kısaltılan inversion of control ve dependency injection prensiplerinden ve bunların avantajlarından bahsedeceğim. Bu yazıyı ve Spring ile alakalı diğer yazıları yazarken kullanacağım birincil kaynak spring.io adresinden ulaşabileceğiniz gayet açıklayıcı hazırlanmış dokümantasyon olacaktır. Diğer kullandığım kaynaklar ise yazıların sonlarında istisnasız belirtilecektir.

IoC (Inversion of Control) ve DI (Dependency Injection)

Öncelikle bu kelimelerin sözlük anlamlarını irdeleyelim. Inversion of Control prensibi, kontrolün tersine dönmesi şeklinde ifade edilebilir. Dependency injection ise bağımlılıkları enjekte etmek demektir. Peki bu iki garip kelime grubu bize yazılım geliştirirken nasıl bir fayda sağlıyor?

Bu prensipleri ve kelime manalarını bir kenara bırakıp kendi tecrübelerinizle düşünün. Bir yazılım geliştirirken programın kontrolü kimdedir? Mesela veritabanı bağlantıları, kullandığınız JDK sürümü, veritabanı bağlantısı açmak için kullandığınız driverlar… Genellikle bir XML dosyası kullanarak veya başka yöntemler kullanarak akışa etki edecek tüm parametreleri belirler ve o şekilde çalıştırırız. Daha farklı bir ifadeyle lineer bir program akışı hazırlarız. Hatta tüm bunlar bir yana String tipinde nesne oluşturma kontrolü bile sizdedir. IoC prensibinin hedeflediği şey ise bundan biraz daha farklıdır. Bu akışın doğrudan programcıdan alınıp başka aktörlere devredilmesini amaçlar. Bu aktörler bir framework, servis veya başka herhangi bir bileşen olabilir. Ama temelinde hepsi program akışının lineer olmaması amacını güder. Peki kontrolü devrettiğimizde bunun bize nasıl bir faydası var? Bu prensip, yazılımda ‘loose-coupling’ olarak geçen başka bir prensibi başarmamızı sağlar. Loose-coupling Türkçe’de “gevşek bağlaşım” olarak karşılaştığım bir terim. Bir nesne yaratırken yaratılan bu nesnenin class’lara veya diğer başka bileşenlere olan bağımlılığının en aza indirilmesi prensibidir. Böylece daha esnek bir kod yazma imkânı elde edilir ve modülerlik sağlanır.

Dependency Injection kavramı ise birçok yerde IoC ile eş anlamlı olarak geçse de kapsam bakımından IoC’den daha dardır. IoC’yi uygulamanın birçok yolu vardır, DI ise bunlardan biridir.

DI yaklaşımında ise temel prensip kodumuzda birbirine bağımlı olan bileşenleri tespit edip, bu bağımlılıkları birbirinden ayırıp bağımsız hale getirmek ve bağımlılıklarını dışarıdan enjekte etmektir. Şimdi yukarıda örnekler vererek anlattığım şeyi bir paragrafta kısaca toparlayayım.

Yazılım geliştirme süreçlerinde modülerliği sağlamak için birçok prensip kullanırız. IoC bunlardan biridir. Kontrolü kodu yazan kişiden alıp başka bir aktöre (mesela framework) teslim etmek demektir. Biz kontrolü teslim ettiğimizde loose-coupling sağlarız. Yani bir nesneyi yaratırken bağımlılıklarını minimuma indirmeyi ve bu bağımlılıklarını da gevşek bağlı yapmaya çalışırız. Peki bu prensipleri uygulamak için ne yaparız sorusunun cevaplarından biri ise dependency injection. Yani bağımlılıkları tespit edip ayırmak ve bu bağlılıkları dışarıdan enjekte etmek. Gördüğünüz üzere birbiriyle iç içe geçmiş üç ayrı kavramdır ve kapsamlarını iyi bilmek gerekir. Şimdi bu soyut tanımları biraz daha somulaştıralım.

IHayvan adında bir interface’imiz olsun. Bu interface yalnızca hayvan sesi çıkarmak için kullanılan sesCikar() metodunun imzasını barındırsın.

public interface IHayvan {
    public void sesCikar();
}

Köpek ve Kedi hayvanlarına ait iki tane de class tanımlayalım.

public class Kopek implements IHayvan {

    @Override
    public void sesCikar() {
	System.out.println("Hav hav hav");
    }
}

public class Kedi implements IHayvan {

    @Override
    public void sesCikar() {
	System.out.println("Miyavv");
    }
}

Hayvan seslerini kullanmak için de bir tane servis tanımlayalım.

public class HayvanService {
    private Kopek hayvan1 = new Kopek();

    public HayvanService() {
	hayvan1.sesCikar();
    }
}

Yukarıda görmüş olduğunuz tasarımda Kopek class’ına ait olan hayvan1 nesnesi tight coupled olarak tanımlanmış. Yani hayvan1 nesnesinin kedi olmasını istesek doğrudan kodda değişiklik yapmamız gerekecek. Bu bize esnek bir yazılım ortamı sunmuyor. Şimdi bu servisi DI ile loose-coupled yapalım.

public class HayvanService {
    IHayvan hayvan1;

    public HayvanService(IHayvan hayvan1) {
	this.hayvan1 = hayvan1;
	hayvan1.sesCikar();
    }
}

Değişikliği, yaptığımız DI tanımıyla şöyle açıklayabiliriz. İlk serviste hayvan1 nesnesi Kopek class’ına bağımlıydı. sesCikar() metodunun çağırılması için bu nesnenin Kopek classının sesCikar() metodunu bilmesi gerekiyordu. İkinci örnekte ise bu bağımlılığı tespit edip kaldırdık. Yerine iki classı da kapsayacak olan “private IHayvan hayvan1” tanımlaması yaptık. Dolayısıyla şimdi istersek Kedi, istersek de Kopek classını gönderip sesCikar() metodunu çağırabiliriz.

private void testiGerceklestir() {

	// Bir hayvan tanımladık ama
	//ne olduğunu seçmedik.
	IHayvan hayvan1;

	// Hayvanı burada kedi olarak seçtim.
	hayvan1 = new Kedi();
	hayvan1.sesCikar();

	// Burada ise köpek.
	hayvan1 = new Kopek();
	hayvan1.sesCikar();

}

Bu kodun çıktısı aşağıdaki gibi olacaktır:

Kodların GitHub linki: https://github.com/kamer/IoCveDI

Yararlandığım Kaynaklar

Bu yazı ilk olarak https://medium.com/topluluk/spring-framework-1-ioc-ve-di-3e2da31bc0e5 adresinde yayınlanmıştır.

Apache JMeter ile REST API Testi

Sun, 10 Jun 2018 22:07:38 +0000

Bu yazımda Apache JMeter kullanarak basit bir REST API testinin nasıl yapıldığını anlatacağım.

Gereklilikler

HTTP methodları hakkında bilgi sahibi olmak.

1. Kurulum

JMeter’ı indirmek için http://ftp.itu.edu.tr/Mirror/Apache//jmeter/ bağlantısına gidin. İndirdikten sonra arşivden çıkarın. Karşınıza şöyle bir klasör yapısı çıkacak.

/bin dizinine giderek “ApacheJMeter.jar” veya “jmeter.bat” dosyalarından birini çalıştırarak programı açıyoruz.

2. HTTP İsteği Göndermek

Programı açtıktan sonra ekran görüntüsünde olduğu gibi Test Plan’e sağ tıklayıp Add -> Thread (Users) -> Thread Group seçeneğine tıklayın. İsteğe bağlı olarak isim verebilirsiniz. Ben bu şekilde devam ediyorum.

Yapacağımız istek Thread Group üzerinde çalışacağı için Thread Group’a sağ tıklayıp Add -> Sampler -> HTTP Request seçeneğine tıklayın.

Ben bu anlatımı test için https://jsonplaceholder.typicode.com/comments?postId=1 üzerinden yapacağım.

Aşağıdaki ekran görüntüsündeki formu şu şekilde dolduruyorsunuz.

Procol: Örneğimizde https.
Server Name or IP: jsonplaceholder.typicode.com
Path: Server Name veya IP’den itibaren soru işaretine kadar olan kısım. (/comments)
Method: Kullanacağınız HTTP metodu.
Send Parameters With The Request: Örneğimizde parametre de göndereceğimiz için burayı da kullanıyoruz. Parametre ise soru işaretinden sonraki kısım, yani “postId=1”.

Son olarak listener ekleyip yaptığımız isteği dinliyoruz. HTTP Request’e sağ tıklayın. Add -> Listener -> View Result Tree seçeneği ile listener’ı oluşturun.

Buraya kadar geldikten sonra ilk testimizi yapalım. Yukarıdaki Start butonuna basarak isteği gönderiyoruz.

Test planını daha sonra kullanmak üzere kaydetmek isteyip istemediğimizi soruyor. Yes diyerek devam ediyorum.

1 numaralı sekmedeki yeşil onay işareti başarılı bir istek atıp cevap aldığınız gösteriyor.
2 numaralı sekmede gönderilen/alınan veri boyutu, bağlantı süresi gibi sonuçlar,
3 numaralı sekmede gönderdiğiniz isteğe dair ayrıntılar,
4 numaralı sekmede size gelen cevap yer alıyor.

3. Toplu İstek Gönderme

Kullandığınız API’nın ne kadar isteğe cevap verebileceğini test etmek isteyebilirsiniz. Bu durumda ise Loop Controller kullanıyorsunuz. Thread Group’a sağ tıklayıp Add -> Logic Controller -> Loop Controller seçeği ile controller oluşturup HTTP Requesti sürükleyip controllerın içine koyuyorsunuz. Eğer bu isteklerin belirli bir gecikmeyle yapılmasını istiyorsanız da Controller’a sağ tıklayıp Add -> Timer -> Constant Timer seçeneğini kullanıyorsunuz. Oraya gecikme süresini ms cinsinde yazdıktan sonra yaptığınız istekler timerda yazan değer kadar gecikmeli olarak loop içinde yazan değer kadar yapılır. Eğer baştan itibaren yazıyı takip ettiyseniz nihai test plan yapısı aşağıdaki şekilde oluyor.

4. XML/CSV Sonuç Alma

Yaptığınız isteklere dair sonuç dokümanı almak için View Result Tree içinde bulunan “Write results to file /Read from the file” yazısının altında bulunan yere kaydetmek istediğiniz yolu ve dosya adını giriyorsunuz. Sağ tarafta bulunan configure seçeneğine tıklayarak doküman içeriğinde neler olmasını istediğinizi yazıyorsunuz. Sonra siz thread’e start dediğinizde dokümanı oluşturup belirlediğiniz yere kaydediyor.

JMeter programının kullanımı bu şekilde. Daha birçok özelliği ve test/sonuç şekilleri var fakat en genel kullanım alanı bu şekilde olduğu için yazıyı burada bitiriyorum. Eğer talep olursa biraz daha ayrıntıya indiğim bir yazı daha yazabilirim. Sorularınızı, katkılarınızı ve eleştirilerinizi bekliyorum.

Bu yazı ilk olarak https://medium.com/topluluk/apache-jmeter-i%CC%87le-rest-api-testi-617d9d377ad8 adresinde yayınlanmıştır.

Kamer's Personal Blog

Java Optional Guide

1. What is the purpose of Optional Class?

2. Creating Optional Objects

2.1 Empty Optional (empty())

2.2 Optional with a value (of())

2.3 Optional with a nullable value (ofNullable())

3. Checking Optionals

3.1 Checking with isPresent();

3.2. Checking with isEmpty();

4. Getting Value From Optional

5. Default Values and Actions

5.1 Get a default value with orElse()

5.2 Throw NoSuchElementException with orElseThrow()

5.3 Throw any exception with orElseThrow()

5.4 Get a default value with a Supplier with orElseGet()

5.5 Return a default Optional with or()

6. Conditional Actions with Lambda Expressions

6.1 ifPresent()

6.2 ifPresentOrElse()

7. Filtering the Value with filter()

8. Mapping Values

8.1 map()

8.2 flatMap()

References

Spring Boot User Registration and Login

Requirements

1. Creating a project with Spring Initialzr

2. Create User entity

3. Create UserService

4. Create ConfirmationToken class

5. User registration process

6. Create confirmation methods

7. Spring Mail config

8. Create EmailService

9. Spring Security Configuration

10. Create controller and pages

Conclusion

How to debug your code in IntelliJ

Requirements

My Motivation

1. Setting breakpoints

1.1 Line Breakpoint

1.2 Method Breakpoint

1.3. Field Watchpoint

1.4. Exception Breakpoint

1.5 Conditional Breakpoint

2. Debug Window

2.1 Step Functions

2.2 Debugger Control Buttons

2.3 Tracing Variables

2.4 Evaluating Expressions and Setting Values Manually

FasterXML/jackson Tips for JSON in Java

Introduction

What is Jackson?

Q1: How to create a Java POJO for any JSON input?

Q2: How to use different field names in POJO to map JSON?

Option 1

Option 2

Q3: How to deserialize nested JSON objects?

Option 1

Option 2

Option 3

Q4: How to create a custom deserializer?

Q5: How to deserialize enum values?

Option 1

Option 2

Option 3

References

Thymeleaf Crash Course

1. Theoretical

1.1 What is Thymeleaf?

1.2 Thymeleaf Standart Dialect

2. Practical

2.1 Folder Hierarchy

2.2 Syntax

2.2.1 Simple Expressions

2.2.2 Constructing Texts

2.2.3 Arithmetic Operations, Comparators and Equality

2.2.4 th:if, th:unless, th:switch, th:case

2.1 Empty Optional (`empty()`)

2.2 Optional with a value (`of()`)

2.3 Optional with a nullable value (`ofNullable()`)

3.1 Checking with `isPresent();`

3.2. Checking with `isEmpty();`

5.1 Get a default value with `orElse()`

5.2 Throw `NoSuchElementException` with `orElseThrow()`

5.3 Throw any exception with `orElseThrow()`

5.4 Get a default value with a Supplier with `orElseGet()`

5.5 Return a default Optional with `or()`

6.1 `ifPresent()`

6.2 `ifPresentOrElse()`

7. Filtering the Value with `filter()`

8.1 `map()`

8.2 `flatMap()`

2.2.4 `th:if`, `th:unless`, `th:switch`, `th:case`

2.2.5 Loops with `th:each`