|
## blogjwa.rb
require_relative '../secrets.rb'
require 'shitpost'
require 'net/https'
require 'uri'
require 'json'
USER = 'Chef'
PASS = TL_PASS
TL_POST_URL = 'https://www.teamliquid.net'
TL_POST_PATH = '/post'
def deliver_garbage(content)
uri = URI.parse(TL_POST_URL)
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
data = "content=#{content}&user=#{USER}&pass=#{PASS}"
headers = {'Content-Type'=> 'application/x-www-form-urlencoded'}
JSON.parse http.post(TL_POST_PATH, data, headers)
end
content = ShitPost.generate('poop')
puts deliver_garbage(content).inspect
## blogjudge.rb
require 'nokogiri'
require_relative '../list_of_users_i_like.rb'
XML_DOC_URL = 'http://www.teamliquid.net/GetLatestUserBlogReplies?User=Chef'
def silently_judge_replies(replies)
def judgement(name)
ARRAY_OF_USERS_I_LIKE.include?(name) ? 5 : (1 + rand(5))
end
judgements = {}
replies.each_with_index do |r, i|
judgements[r['name']] ||= []
judgements[r['name']] << { i => judgement(r['name']) }
end
judgements
end
def return_replies_hash
doc = Nokogiri::XML(open(XML_DOC_URL))
Hash.from_xml(doc.xpath('//replies').to_s)
end
replies = return_replies_hash
judgements = silently_judge_replies(replies)
puts judgements.inspect
## crontab
0 0 * * 0 /usr/local/rvm/gems/ruby-2.0.0-p353@tl/wrappers/ruby /home/dev/tl/scripts/blogjwa.rb > /home/dev/cron-debug.txt 2>&1
0 * * * * /usr/local/rvm/gems/ruby-2.0.0-p353@tl/wrappers/ruby /home/dev/tl/scripts/blogjudge.rb > /home/dev/cron-debug.txt 2>&1
  
|
East Gorteau22261 Posts
I don't know what this is so I will do the very internet thing, assume it's clever/funny and 5/5
|
Consider your assumption silently judged then.
|
East Gorteau22261 Posts
On November 23 2015 09:13 LightTemplar wrote:
Consider your assumption silently judged then.
It's ok I'm a writer all I do is have my thoughts judged anyway
|
This is what happens to an English major who becomes a programmer
|
The real horror is that I've edited this 3 times realising there are bugs in my fake code.
2.1.3 :005 > ary = ['Zealously', 'LightTemplar', 'Zealously', 'Ilikestarcraft']
=> ["Zealously", "LightTemplar", "Zealously", "Ilikestarcraft"]
2.1.3 :006 > def judgement(ary); ary.each {|n| puts "#{n} #{(1 + rand(5))}" } end
=> :judgement
2.1.3 :007 > judgement ary
Zealously 4
LightTemplar 4
Zealously 3
Ilikestarcraft 2
Harsh. Luckily the real program accounts for ils and makes him a 5 
|
System.out.println("5/5")
|
stars ||= 5
This made me stop for a couple minutes and see if i could break it.
|
Japan11286 Posts
comments = [ 'This is Ruby right? First time seeing Ruby code', 'The syntax looks close to Python', 'Anyway 5/5 until I can actually read Ruby']
for comment in comments:
printf comment
|
Sure it will throw a nullpointerexception.
|
public void learnRuby(){
// todo
}
|
Is your handle in reference to Chef?
Also obligatory ewww ruby {{My language}} is so much better.
|
GRAND OLD AMERICA16375 Posts
why are you requiring nokogiri ? should only need the "passion" directive
|
Haha the silent judge and people I like bits. haha
|
Canada11355 Posts
##Feast.rb
require 'shitpost'
def chew()
# Find something to eat
food = ShitPost.generate('poop')
# Break food down into an array of separate words spitting out any punctuation or spaces
food.split(/\W+/).map(&:to_s)
swallow(food)
end
def swallow(food)
stomach = []
churn = false
#digest words into letters
for chunks in food
if churn == false
churn = true
else
churn = false
chunks.split(//)
# jumble letters into stomach array
for mush in chunks
if churn == true
stomach.unshift(mush)
else
stomach << mush
end
end
vomit(stomach)
end
def vomit(stomach)
#regurgitate contents of stomach until empty
for bile in stomach
puts bile
end
puts "I feel much better now"
end
chew()
I only really know python so I googled a lot of things for this but unless I misunderstand what the module shitpost does I think this would work
|
I think the chew method can be improved by not including the swallow call. What happens when you want to write code where the shit post is immediately regurgitated to feed your young? Also the swallow method is not in scope, so it won't work. Chew should really take the argument food, not generate the food.
As a personal preference, I dislike comments which are not explaining an unusual piece of code that would make another programmer wonder why you did it a specific way. The method containing the code should generally be enough to tell you what it does.
|
Canada11355 Posts
I was writing the comments to explain to me what I wanted to program to do. I lack organization and writing things down before I can articulate them in code keeps me on track.
What does 'in scope' mean? I'm fairly green at programming and just make tools that I can't find with a simple google search.
Are you saying it would be better to have a separate method for finding food, then feed that variable through chew's parameter brackets?
|
The OP's post was clever but fecalfeast's was art. The form perfectly embellished the content. And his topical name was the cherry on top of the cow pie.
Critiquing his code here is like stopping a singer to correct his lyrics.
|
On November 24 2015 11:15 Fecalfeast wrote:
I was writing the comments to explain to me what I wanted to program to do. I lack organization and writing things down before I can articulate them in code keeps me on track.
What does 'in scope' mean? I'm fairly green at programming and just make tools that I can't find with a simple google search.
Are you saying it would be better to have a separate method for finding food, then feed that variable through chew's parameter brackets?
Sure, it's not problem. I like to write methods I wish existed when thinking about the top level logic of my code, and then write the methods.
My bad about the scope, your methods are all in the global scope so they are accessible to one another.
ex
2.1.3 :001 > def bear; puts 'bear'; end
=> :bear
2.1.3 :002 > def kuma; puts bear; end
=> :kuma
2.1.3 :003 > kuma
bear
In larger applications, you have to throw things into classes and modules, so that you can avoid naming collisions by polluting the global scope (you can google javascript global scope for a typical explanation).
If for example you had defined method A within method B, you wouldn't be able to access method A outside method B. Similarly, if you define methods within a class, you can access them anywhere within the class, but outside the class you have to call Class.method (or if you have an instance of the class, instance.method).
I'm just saying your method chew does not describe accurately enough what it does, which is find food and digest it and vomit it out. So when someone calls chew they will get the unexpected result of vomit. Really your method would be accurately called find_food_eat_it_and_vomit_it_out which is a method that seems to have a lot of responsibilities. If I wrote such a method, it would have calls to three other methods, find_food eat_food (which has chew_food and swallow_food methods) vomit_food. This way the code is more reusable, the stack trace will be easier to read, and if you need to update one of them, all your methods that use them will be updates simultaneously, instead of you having to update the same code in multiple places.
Even if all you use code for is one off scripts for yourself, it might help you to build a library of methods you often need to use (which you could do a very simple require to have accessible in all your scripts, saving you some copy / pasting). Naming those methods logically will help you to remember without referencing them.
|
After a hard day at work, coding, I open at TL, then "yes a Chef blog"... meh
...
Chef, how about an "Allow me to analyze your code writing" ;-)
|
Canada11355 Posts
On November 24 2015 11:36 patrick321 wrote:
The OP's post was clever but fecalfeast's was art. The form perfectly embellished the content. And his topical name was the cherry on top of the cow pie.
Critiquing his code here is like stopping a singer to correct his lyrics.
I actually appreciate the advice, I often run into annoying problems that are often just fixed by being more organized. Besides, if his OP is a shitpost, my post is literally regurgitated shit.
On November 24 2015 23:31 Chef wrote:Show nested quote +On November 24 2015 11:15 Fecalfeast wrote:
I was writing the comments to explain to me what I wanted to program to do. I lack organization and writing things down before I can articulate them in code keeps me on track.
What does 'in scope' mean? I'm fairly green at programming and just make tools that I can't find with a simple google search.
Are you saying it would be better to have a separate method for finding food, then feed that variable through chew's parameter brackets? Sure, it's not problem. I like to write methods I wish existed when thinking about the top level logic of my code, and then write the methods. My bad about the scope, your methods are all in the global scope so they are accessible to one another. ex 2.1.3 :001 > def bear; puts 'bear'; end => :bear 2.1.3 :002 > def kuma; puts bear; end => :kuma 2.1.3 :003 > kuma bear In larger applications, you have to throw things into classes and modules, so that you can avoid naming collisions by polluting the global scope (you can google javascript global scope for a typical explanation). If for example you had defined method A within method B, you wouldn't be able to access method A outside method B. Similarly, if you define methods within a class, you can access them anywhere within the class, but outside the class you have to call Class.method (or if you have an instance of the class, instance.method). I'm just saying your method chew does not describe accurately enough what it does, which is find food and digest it and vomit it out. So when someone calls chew they will get the unexpected result of vomit. Really your method would be accurately called find_food_eat_it_and_vomit_it_out which is a method that seems to have a lot of responsibilities. If I wrote such a method, it would have calls to three other methods, find_food eat_food (which has chew_food and swallow_food methods) vomit_food. This way the code is more reusable, the stack trace will be easier to read, and if you need to update one of them, all your methods that use them will be updates simultaneously, instead of you having to update the same code in multiple places. Even if all you use code for is one off scripts for yourself, it might help you to build a library of methods you often need to use (which you could do a very simple require to have accessible in all your scripts, saving you some copy / pasting). Naming those methods logically will help you to remember without referencing them.
So separating them into
def find_food()
stuff
end
def chew()
differentStuff
end
def swallow_digest()
otherStuff
end
def vomit()
endResult
end
def indigestion()
find_food()
while food
chew()
swallow_digest()
vomit()
puts "I'm hungry again"
end
indigestion()
would be better because it's easier to tell where something goes wrong when something goes wrong?
|
On November 25 2015 12:23 Fecalfeast wrote:Show nested quote +On November 24 2015 11:36 patrick321 wrote:
The OP's post was clever but fecalfeast's was art. The form perfectly embellished the content. And his topical name was the cherry on top of the cow pie.
Critiquing his code here is like stopping a singer to correct his lyrics. I actually appreciate the advice, I often run into annoying problems that are often just fixed by being more organized. Besides, if his OP is a shitpost, my post is literally regurgitated shit. Show nested quote +On November 24 2015 23:31 Chef wrote:On November 24 2015 11:15 Fecalfeast wrote:
I was writing the comments to explain to me what I wanted to program to do. I lack organization and writing things down before I can articulate them in code keeps me on track.
What does 'in scope' mean? I'm fairly green at programming and just make tools that I can't find with a simple google search.
Are you saying it would be better to have a separate method for finding food, then feed that variable through chew's parameter brackets? Sure, it's not problem. I like to write methods I wish existed when thinking about the top level logic of my code, and then write the methods. My bad about the scope, your methods are all in the global scope so they are accessible to one another. ex 2.1.3 :001 > def bear; puts 'bear'; end => :bear 2.1.3 :002 > def kuma; puts bear; end => :kuma 2.1.3 :003 > kuma bear In larger applications, you have to throw things into classes and modules, so that you can avoid naming collisions by polluting the global scope (you can google javascript global scope for a typical explanation). If for example you had defined method A within method B, you wouldn't be able to access method A outside method B. Similarly, if you define methods within a class, you can access them anywhere within the class, but outside the class you have to call Class.method (or if you have an instance of the class, instance.method). I'm just saying your method chew does not describe accurately enough what it does, which is find food and digest it and vomit it out. So when someone calls chew they will get the unexpected result of vomit. Really your method would be accurately called find_food_eat_it_and_vomit_it_out which is a method that seems to have a lot of responsibilities. If I wrote such a method, it would have calls to three other methods, find_food eat_food (which has chew_food and swallow_food methods) vomit_food. This way the code is more reusable, the stack trace will be easier to read, and if you need to update one of them, all your methods that use them will be updates simultaneously, instead of you having to update the same code in multiple places. Even if all you use code for is one off scripts for yourself, it might help you to build a library of methods you often need to use (which you could do a very simple require to have accessible in all your scripts, saving you some copy / pasting). Naming those methods logically will help you to remember without referencing them. So separating them into def find_food()
stuff
end
def chew()
differentStuff
end
def swallow_digest()
otherStuff
end
def vomit()
endResult
end
def indigestion()
find_food()
while food
chew()
swallow_digest()
vomit()
puts "I'm hungry again"
end
indigestion() would be better because it's easier to tell where something goes wrong when something goes wrong?
Its part of the SOLID principles, single responsibility for methods/functions/class each method should only do one thing (ie. swallow and chew are two different things)
This allows for ease of testing and future proofing because if you need to change how chewing works it shouldnt impact (as much) anything else. Also if you have tests written then after you make a change you rerun your tests and it tells you either where there are issues or that your change is fine. If you have a giant method then if your test fails you dont really know what failed as it was just something in that method, where as if it is broken out you can tell "oh the swallow part didnt work, lets go fix it"
|
try:
Chef is "Funny"
print(" Best post ever 5/5!! ")
except ValueError:
print("I will probably get banned for it but i have to say...........")
sys.exit()
|
+1 for require_relative
Whoops, thought we were on Github 
|
|
|
|
|
|
EPT
