DEV Community: minhtienvu

How to upgrade Github Profile to PRO highlight ABSOLUTELY FREE in 5 minutes 💥💥💥

minhtienvu — Mon, 21 Mar 2022 02:31:32 +0000

Hi everyone, It's Tien again, I have been diving for a while because I am too lazy to write. Today I will share with you know to upgrade your Github to PRO highlight but TOTALLY FREE in 5 minutes 💝💝💝

If you have a PRO highlight, you can use some services like GitKraken, Jetbeans v..v totally free. You can see full of free services at this link: https://education.github.com/pack

Just listening to FREE is exciting, isn't it? =))

Don't forget to give me a like and donate me in there: https://tienvm.com/donate

The result after upgrading to Github PRO will be like this. Rest assured that the steps below will help you upgrade FULLY FREE and extremely easy...Look at the genuine profile:v

1. What is Github PRO?

For a long time, we must have used GitHub by personal email. Many people will not know that Github allows us to pay to use more services and other features.

If you do not upgrade and use the default service when creating a new account. Then we usually use the Github Free package. You can go to Settings -> Billing & plans and look under Current plan. This is our current package.

For example, this is an account that people often use, without paying.

2. What are the benefits of Github Pro?

If people want to use many other services and features of Github, people will have to upgrade. Everyone will see an Upgrade button in the Current plan section like this → Click it

You will find it will cost at least 4$/user/month to upgrade the team plan and 21$/user/month for the enterprise plan. Everyone can see there are many benefits if we use premium packages, right???

Comparison between Free and Paid plans: https://github.com/settings/billing/plans

⇒ Rest assured that today I will guide everyone to upgrade to the 4$/user/month package FULLY FRE. Just have to say it over and over again:v

3. How can I upgrade to Github Pro for free?

We have 3 ways:

The first way is that you have to pay free, of course, but I'm poor =))
The second way is to use an educational email with a .edu extension. The way I will guide you in this article... Prestige!!
The last one if you do not have a .edu email, you just take a picture of your student card or something similar and it will be approved(A man suggest it to me but I did not try it so you can try it).

=> I will guide everyone in Way 2!!

Services, tools, websites.. support access, use if you are a student: See all here: https://education.github.com/pack

4. Steps to upgrade Github PRO

Step 1: Access the Github student link:

https://education.github.com/discount_requests/student_application. You will see a form like like this.

Step 2: Complete the form. Steps to complete the form:

Add email at Add an email address button ⇒ After pressing this button, item 2 will be displayed.
In section 2 "Please add..." => Click here I underlined, it will link to Setting Emails in your Github

In this paragraph, you add your edu email and a verify emaill will send through a Github email just entered.

=> After adding edu email and successful authentication, it will look like this.

Step 3: Go back to the form fillng in Github Student just now(Picture step 1), reload the page, you will see that the edu email has been added successfully, it will be displayed like this

Step 4: Complete the "How do you play to use Github" section and press `Continue`

Step 5: DONE. After completing the form, a successful submission message will be displayed and you need to check your email

=> NOTE: Notifications will take a few days to receive emails but it's optional. After I submitted it, I received it within 5 minutes LOL 😂😂

After only receiving the email, the result is that you have successfully upgraded to the PRO package but TOTALLY FREE 😂😂

5. Summary

One of the many benefits, when your Github account becomes PRO, is being able to use GitKraken GUI tools to view and manipulate Git more easily and many other services..

Everyone can refer to the services and support tools for Students here:
https://education.github.com/pack

Thank you all for taking the time to read my post. Please like and upvote the article if you find it useful. Don't be afraid to leave a comment so we can interact and learn from each other 💝💝💝

My blog: https://tienvm.com

Donate me: https://tienvm.com/donate

Some helpful syntax/conventions in Rails to you 🍵🍵

minhtienvu — Thu, 17 Mar 2022 07:53:23 +0000

Some helpful syntax/conventions in Rails to you

Hi guys, Tien again, after I read some articles and my hands-on experience in some Rails projects. I write this post to summarize some helpful conventions that can improve your Rails knowledge.

Sip a cup of tea and enjoy it ❤️ Have fun guys!!

1. Use `_` in the console to get the value of the previous command in your console

YOUR CONSOLE

a = [1,2,3,4,5]

User.where(id: _)
=> SELECT `users`.* FROM `users` WHERE `users`.`id` IN (1, 2, 3, 4, 5)

2. Existence Check Shorthand

Use &&= to set variables that may or may not exist. Using &&= will change the value only if it exists, removing the need to check its existence with if. Use &&= to set variables that may or may not exist. Using &&= will change the value only if it exists, removing the need to check its existence with if.

# bad
if something
  something = something.downcase
end

# bad
something = something ? something.downcase : nil

# ok
something = something.downcase if something

# good
something = something && something.downcase

# better
something &&= something.downcase

3. `map`/`find`/`select`/`reduce`/`include?`/`size`

Prefer map over collect, find over detect, select over find_all, reduce over inject, include? over member? and size over length. This is not a hard requirement; if the use of the alias enhances readability, it’s ok to use it. The rhyming methods are inherited from Smalltalk and are not common in other programming languages. The reason the use of select is encouraged over find_all is that it goes together nicely with reject and its name is pretty self-explanatory.

3.1. count vs size

Don’t use count as a substitute for size. For Enumerable objects other than Array it will iterate the entire collection in order to determine its size.

# bad
some_hash.count

# good
some_hash.size

3.2. flat_map

Use flat_map instead of map + flatten. This does not apply for arrays with a depth greater than 2, i.e. if users.first.songs == ['a', ['b','c']], then use map + flatten rather than flat_map. flat_map flattens the array by 1, whereas flatten flattens it all the way.

# bad
all_songs = users.map(&:songs).flatten.uniq

# good
all_songs = users.flat_map(&:songs).uniq

4. Conditional Variable Initialization Shorthand

Use ||= to initialize variables only if they’re not already initialized.

# bad
name = name ? name : 'Bozhidar'

# bad
name = 'Bozhidar' unless name

# good - set name to 'Bozhidar', only if it's nil or false
name ||= 'Bozhidar'

**NOTE: Don’t use ||= to initialize boolean variables. 
Consider what would happen if the current value happened to be false.**

# bad - would set enabled to true even if it was false
enabled ||= true

# good
enabled = true if enabled.nil?

5. Underscores in Numerics

Add underscores to large numeric literals to improve their readability.

# bad - how many 0s are there?
num = 1000000

# good - much easier to parse for the human brain
num = 1_000_000

6. Convert a range to an array

I use some below syntax to convert a range to an array. I hope that you can apply it

(1..10).to_a
=> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

7. Get array characters from a string

# bad
string.split(//)
string.split('')

# good
string.chars

8. Prefer to use `Time.current, Date.current or DateTime.current` rather than `Time.now, Date.now, DateTime.now`

.current will use the Rails environment is set to, .now will use server's timezone (Rails.application.config.time_zone). If it's not set, then .current
will be the same as .now .Be careful when use them to avoid conflict and unmatched.

Time.current
=> Returns Time.zone.now when Time.zone or config.time_zone are set,
otherwise just returns Time.now.

DateTime.current
=> Returns Time.zone.now.to_datetime when Time.zone or config.time_zone are set,
otherwise returns Time.now.to_datetime.

9. Predicate Methods

Prefer the use of predicate methods to explicit comparisons with ==. Numeric comparisons are OK.

# bad
if x % 2 == 0
end

if x % 2 == 1
end

if x == nil
end

# good
if x.even?
end

if x.odd?
end

if x.nil?
end

if x.zero?
end

if x == 0
end

10. Hash#values_at

Use Hash#values_at when you need to retrieve several values consecutively from a hash.

# bad
email = data['email']
username = data['nickname']

# good
email, username = data.values_at('email', 'nickname')

11. Proc Application Shorthand

Use the Proc call shorthand when the called method is the only operation of a block.

# bad
names.map { |name| name.upcase }

# good
names.map(&:upcase)

12. Single-line Blocks Delimiters

Prefer {…} over do…end for single-line blocks. Avoid using {…} for multi-line blocks (multi-line chaining is always ugly). Always use do…end for "control flow" and "method definitions" (e.g. in Rakefiles and certain DSLs). Avoid do…end when chaining.

names = %w[Bozhidar Filipp Sarah]

# bad
names.each do |name|
  puts name
end

# good
names.each { |name| puts name }

# bad
names.select do |name|
  name.start_with?('S')
end.map { |name| name.upcase }

# good
names.select { |name| name.start_with?('S') }.map(&:upcase)

Some will argue that multi-line chaining would look OK with the use of {…}, but they should ask themselves - is this code really readable and can the blocks' contents be extracted into nifty methods?

13. Defining Class Methods

Use def self.method to define class methods. This makes the code easier to refactor since the class name is not repeated.

class TestClass
  # bad
  def TestClass.some_method
    # body omitted
  end

  # good
  def self.some_other_method
    # body omitted
  end

  # Also possible and convenient when you
  # have to define many class methods.
  class << self
    def first_method
      # body omitted
    end

    def second_method_etc
      # body omitted
    end
  end
end

14. `Hash#each`

Use Hash#each_keyinstead of Hash#keys.each and Hash#each_value instead of Hash#values.each

# bad
hash.keys.each { |k| p k }
hash.values.each { |v| p v }
hash.each { |k, _v| p k }
hash.each { |_k, v| p v }

# good
hash.each_key { |k| p k }
hash.each_value { |v| p v }

15. `Hash#fetch`

Use Hash#fetch when dealing with hash keys that should be present.

heroes = { batman: 'Bruce Wayne', superman: 'Clark Kent' }
# bad - if we make a mistake we might not spot it right away
heroes[:batman] # => 'Bruce Wayne'
heroes[:supermann] # => nil

# good - fetch raises a KeyError making the problem obvious
heroes.fetch(:supermann)

16. `Hash#fetch` defaults

Introduce default values for hash keys via Hash#fetch as opposed to using custom logic.

batman = { name: 'Bruce Wayne', is_evil: false }

# bad - if we just use || operator with falsy value we won't get the expected result
batman[:is_evil] || true # => true

# good - fetch works correctly with falsy values
batman.fetch(:is_evil, true) # => false

17. Use Hash Blocks

Prefer the use of the block instead of the default value in Hash#fetch if the code that has to be evaluated may have side effects or be expensive.

batman = { name: 'Bruce Wayne' }

# bad - if we use the default value, we eager evaluate it
# so it can slow the program down if done multiple times
batman.fetch(:powers, obtain_batman_powers) # obtain_batman_powers is an expensive call

# good - blocks are lazy evaluated, so only triggered in case of KeyError exception
batman.fetch(:powers) { obtain_batman_powers }

18. `Hash#transform_keys` and `Hash#transform_values`

Prefer transform_keys or transform_values over each_with_object or map when transforming just the keys or just the values of a hash.

# bad
{a: 1, b: 2}.each_with_object({}) { |(k, v), h| h[k] = v * v }
{a: 1, b: 2}.map { |k, v| [k.to_s, v] }.to_h

# good
{a: 1, b: 2}.transform_values { |v| v * v }
{a: 1, b: 2}.transform_keys { |k| k.to_s }

19. `reverse_each`

Prefer reverse_each to reverse.each because some classes that include Enumerable will provide an efficient implementation. Even in the worst case where a class does not provide a specialized implementation, the general implementation inherited from Enumerable will be at least as efficient as using reverse.each.

# bad
array.reverse.each { ... }

# good
array.reverse_each { ... }

20. Unused Variables Prefix

Prefix with _ unused block parameters and local variables. It’s also acceptable to use just _
(although it’s a bit less descriptive). This convention is recognized by the Ruby interpreter and tools like RuboCop will suppress their unused variable warnings.

# bad
result = hash.map { |k, v| v + 1 }

def something(x)
  unused_var, used_var = something_else(x)
  # some code
end

# good
result = hash.map { |_k, v| v + 1 }

def something(x)
  _unused_var, used_var = something_else(x)
  # some code
end

# good
result = hash.map { |_, v| v + 1 }

def something(x)
  _, used_var = something_else(x)
  # some code
end

❤️ Thank you for reading and see you ❤️
Follow me: https://tienvm.com/
Donate me: tienvm.com/donate