|
Marc Clifton wrote: Because RoR is interpreted, it means that I don't have to recompile the app to see changes -- I can make changes to the model, controllers, and of course the views without having to restart the server. Makes development a breeze.
I'm about 70 coding hours into a RoR/AngularJS/Coffeescript project (all 3 new to me); and am finding about 2/3rds of my debug time is being spent on issues that a compiled/strongly typed language would've called me out on immediately; even ignoring that VS (or even Eclipse) >> Sublime my dev rate's a lot slower than on other platforms.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: and am finding about 2/3rds of my debug time is being spent on issues that a compiled/strongly typed language would've called me out on immediately;
Absolutely. Duck-typing is a productivity-killer in my opinion. Type inference is another killer in an interpreted context. At least in F#, the IDE detects issues even before you compile the code, though it is possible to fool it.
To help with that, what I do is the following:
* I use very descriptive function names, variable names, and parameter names
* I write very small functions that do just one thing
* I comment every single function, describing the input and output types so I know how to use the function later on
* I heavily comment the code
* I refactor constantly -- as soon as I see some duplicate code, I refactor it into a single function
* I step through every line of code (I tend to do that in C# as well, so it's not really a development hit)
* I explicitly specify the return value, even if it's redundant.
* Liberal use of white space.
Notice I didn't say that I write tests or work in a TDD paradigm. The main reason is that it takes a while to fire up the unit tests, which is yet another hit on development time, not to mention writing the tests.
Lastly, there's a lot of "idiomatic" Ruby which is really cool and sexy and geeky but is totally incomprehensible at first glance. I always refactor those into functions that explicitly state what's going on. The idea is that the high level code should tell me what it's doing, and the low level code tells me how it's doing it.
Here's an example:
How:
# Given comma separated values in a string, returns an array of strings, stripping leading
# and trailing whitespace.
def csv_to_array(csv)
array = csv.split(',').collect{|s| s.strip}
array
end
What:
# Adds children (given in csv format) to an entity.
def add_children(entity, csv_children)
child_list = csv_to_array(csv_children)
entity.add_children(child_list, self.project_id)
end
Hope that helps! (And gee, I think I'm going to copy this reply and post it on my blog!)
Marc
|
|
|
|
|
every time I've tried breaking most/all of my code into methods that small I found myself spending more time chasing up/down the call stack than anything else and with productivity even lower than when trying to wade though multi-hundred line method failure.
I've never been a fan of test first coding; but enough tests to catch regression failures has always been something I've liked. The problem I'm having here, and why I started a thread about a ruby CI server, is people being sloppy about remembering to update tests when they did change something: Did you break it? Did merging your changes with mine break it? Did git hork up the auto merge badly? ... is my second biggest pain point on the project atm.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: when trying to wade though multi-hundred line method failure
Ugh, sounds like you've inherited some really bad code. I tend to find that myself, which has led me to develop my own "best practices" when writing Ruby code.
Dan Neely wrote: Did git hork up the auto merge badly? ... is my second biggest pain point on the project atm.
Don't even get me started regarding Git. 
Marc
|
|
|
|
|
Marc Clifton wrote: Dan Neely wrote: when trying to wade though multi-hundred line method failure
Ugh, sounds like you've inherited some really bad code. I tend to find that myself, which has led me to develop my own "best practices" when writing Ruby code.
Yeah. The prototype, will be replaced once we figure out what it needs to do, excel/VBA code written by a very junior dev ended up lasting almost a decade in production before we could afford to rewrite it. And even there timing pressure meant we had to bring on a few devs who didn't have the domain knowledge needed to do anything other than literalport some modules from VBA to C#; and I'm probably 2 years from having enough time to finally finish refactoring the last into something minimally sane.
Marc Clifton wrote: Dan Neely wrote: Did git hork up the auto merge badly? ... is my second biggest pain point on the project atm.
Don't even get me started regarding Git.
...I think if I really got going I'd end up needing a Nagy's worth of gin, a Dalek's worth of beer, and MM's worth of rum, and a few bottles of Rodger's scotch before I finished; and probably a liver transplant too. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: ...I think if I really got going I'd end up needing a Nagy's worth of gin, a Dalek's worth of beer, and MM's worth of rum, and a few bottles of Rodger's scotch before I finished; and probably a liver transplant too.
Oh, that is SO quotable!
Probably would be easier re-writing Git to something that was usable. Oh wait, we have usable source control systems already!
Marc
|
|
|
|
|
Marc Clifton wrote: Probably would be easier re-writing Git to something that was usable. Oh wait, we have usable source control systems already!
Yup. At my employer git (instead of Hg) appears to've snowballed as the dvcs of choice for no other reason than it being the personal favorite of the first person to decide the risk of something without any corporate IT support was worth avoiding the performance misery of trying to use SVN over the VPN. 
Ruby appears to've won out for buzzword compliant webdev for the same reason; and VS has just announced support for node.js too. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I see someone's had a similar experience as I. Coming into Ruby-on-Rails (RoR) after working with Python/Django, and C# ASP.NET-MVC, my productivity really schlowed to a crawl with RoR. The duck-typing is one factor: I much, much prefer to just have things explicit within the code structure so I can know what's going on. C# catches most of the errors that RoR happily lets slide and condemns you to hours of guessing and troubleshooting.
Another huge factor is - with RoR, things rarely actually work. It seems there's a wealth of online information that is incorrectly typed, or that just doesn't work as claimed. Things break with various versions, or are incompatible with, or there're way too many ways to accomplish the same thing. I came to the conclusion that the reason we see more online activity with RoR is: nothing's working, and everyone is still googling trying to find something that does! It is probable that I'd have had a better RoR experience had it been my very first development platform: I got so spoiled with C# and ASP.NET-MVC that RoR is a horror-show of incompatible, non-working madness.
James Hurst
James Hurst
"The greatness of a nation and its moral progress can be judged by the way its animals are treated."
Mahatma Gandhi
|
|
|
|
|
Out of curiosity, why did you choose Msys2 rather than RailsInstaller?[^]
I've been using RailsInstaller for over a year now and have never had problems with it.
Marc
|
|
|
|
|
A more unixy environment, actually. Also has a ton of other useful packages for development.
Getting information off the Internet is like taking a drink from a fire hydrant.
- Mitchell Kapor
|
|
|
|
|
Can't say I've tried RailsInstaller.
I have used both rb.env and rvm.
RVM is home heavy weight, but it's the reigning champion.
rb.env is coming up fast though.
|
|
|
|
|
I ended up hitting a bunch of errors with Msys2, so I am now just going to use RubyInstaller (2.0.0-p353) and install Rails on that. I am using RubyMine as the IDE (it is good).
Getting information off the Internet is like taking a drink from a fire hydrant.
- Mitchell Kapor
|
|
|
|
|
Brisingr Aerowing wrote: so I am now just going to use RubyInstaller (2.0.0-p353) and install Rails on that.
It has Rails already pre-installed.
Brisingr Aerowing wrote: I am using RubyMine as the IDE (it is good).
Indeed it is!
Good luck, let me know if you run into any problems.
Marc
|
|
|
|
|
RubyInstaller, not RailsInstaller. Last time I looked, RailsInstaller was out of date (I like to use the latest stuff when I can)
Getting information off the Internet is like taking a drink from a fire hydrant.
- Mitchell Kapor
|
|
|
|
|
Brisingr Aerowing wrote: RubyInstaller, not RailsInstaller.
Ah, my bad.
Yes, RubyInstaller isn't up to version 2 of Ruby and Rails yet, but for my purposes, neither is my client's code, and at least in Rails, there are some significant breaking changes.
Marc
|
|
|
|
|
Give a try to a vagrant box. There is one ready for RoR development here[^].
It runs a small linux server on a virtual box and forwards all needed ports to your computer, so you can keep your browser, your text editor (are you using Sublime?), git and so on on your machine.
It is tricky to compile some gems on Windows, so it is much better to have a linux environment to handle it all.
Hope this helped 
|
|
|
|
|
'.. I can post a link to the system I set up here..'
Yes, and TIA
sss-ed
|
|
|
|
|
|
Sold
Just need a check big enough to buy it, and another big enough to drop off at Hennessey[^] and say "go nuts".
|
|
|
|
|
Might be a tad expensive...1200HP??? Wow, that will get you REAL fast from gas station to gas station.
|
|
|
|
|
Pretty picture.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
This[^] is a Blade MCPX. Don't let its size and plain appearance fool you. It's a real little helicopter that can take a few crashes and is therefore ideal for learning how to fly.
But it's really not much to look at. Now, what if I remove everything that's not needed and install the rest in a more interesting hull? One like this.[^] Yes, I know that's a regular model kit. We will have to make some modifications, but it could work. At least should a Huey at 1:48 scale have enough room to install everything and it looks promising.[^]
And this[^] is how far I got today: The hull from the model kit is glued together and primed, but not yet sanded. The Blade's chassis has been installed inside and fits, but I had to cut out parts of the roof to make room for the larger swashplate. I had to break the tail boom assembly when I took it off. The tail motor is now installed in the model, but the wires still have to be routed to the front and again attached to the circuit board.
Provided I get the tail motor functional again, find a good place for the battery and manage to get it trimmed, then it may actually fly. How are my odds?
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript.
modified 11-Jan-14 17:22pm.
|
|
|
|
|
Odds of it flying? Not great. It'll get into the air, but with the body you've added you may have significantly changed the CG of the model. Even though they are cool little helicopters, they can't really take much of a change in CG (try taping a dime to one near the nose or tail). You may need to add weight to some part to get it to hover. If you managed to get the CG right then you will have to tune it so it doesn't spin, but most have a little knob on the controller for that. That's because of the additional side surface area near the tail rotor can be counter productive (see below, same reason).
Another problem is that it may take significantly more throttle to lift off. You've added a lot of surface area under the rotor that isn't effective (actually its counter-productive), the problem is that the force of the blades pushing air down on top of the new body adds, essentially, weight. You're basically decreasing the effective rotor area while increasing weight.
It'll be interesting to see how it flies, definitely come back and tell us!
|
|
|
|
|
I already learned the hard way what happens when the tail or the nose are too heavy. Taping a coin to the nose or the tail as needed will certainly be required before flying.
Spinning could be a lesser problem. Yesterday I spent some time to find a model with a similar spacing between the rotors and enough space to install everything at a given scale. My first choice would have been a Mi-24 at 1:72. The distance between the rotors would have been ideal, but in the front the model would have been far too narrow.
My greatest worry also is that the motor may not be strong enough. Still, the model kit was not very expensive and I can always put the MCPX back together if it does not work at all. But I don't give up that easily. It took me a while, but I have taken apart and modified my Blade 130X until that tail wagging finally was gone.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript.
|
|
|
|
|
I say your odds are terrific! Congratulations on the idea and the workmanship.
I love RC helis.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
