Announcement

Collapse
No announcement yet.

Announcement

Collapse
No announcement yet.

***VD 13 Spreadsheet***

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Updated with a new spreadsheet (link in the first post of this thread, and also in the history thread).

    New fixes in Version 1.1:
    17. Removed 20 duplicate hitter seasons from 1959.
    18. Remove the 14th drafter slot from various worksheets
    19. Update the standings rankings to reflect 13 teams instead of 14
    20. Update team sheets to reflect OBP instead of AVG
    "Jesus said to them, 'Truly I tell you, the tax collectors and the prostitutes are going into the kingdom of God ahead of you.'"

    Comment


    • #17
      Originally posted by Controller Jacobs View Post
      There may be two relevant pitching bys missing

      These were both taken in vd10:
      papeljo01_2014
      streehu01_2014

      If they are indeed missing, the Street one looks more important. The Papelbon one must have been a very specific need.
      I'll plan to catch this when I update pitcher stats.

      Do you have the ability to check the BB-Ref IDs for the players I added from 2013 onwards?
      "Jesus said to them, 'Truly I tell you, the tax collectors and the prostitutes are going into the kingdom of God ahead of you.'"

      Comment


      • #18
        Originally posted by Kevin Seitzer View Post
        I'll plan to catch this when I update pitcher stats.

        Do you have the ability to check the BB-Ref IDs for the players I added from 2013 onwards?
        I have a nice bbref player id lookup for 2018 on the crashed machine. If it comes back up, I'll be able to check from that. I also have 2013-2017 - that's easier to rebuild since it's in that database that I downloaded.
        people called me an idiot for burning popcorn in the microwave, but i know the real truth. - nullnor

        Comment


        • #19
          One quirk I noticed/remembered is that Lahman and BB-Ref differ on the playerID for Kevin Youkilis. I believe we were using Lahman's ID (youkike01) instead of BB-Ref (youklke01). I personally don't care which as long as we standardize on one.
          "Jesus said to them, 'Truly I tell you, the tax collectors and the prostitutes are going into the kingdom of God ahead of you.'"

          Comment


          • #20
            Originally posted by Kevin Seitzer View Post
            One quirk I noticed/remembered is that Lahman and BB-Ref differ on the playerID for Kevin Youkilis. I believe we were using Lahman's ID (youkike01) instead of BB-Ref (youklke01). I personally don't care which as long as we standardize on one.
            I vote BB-ref since it's easier to get to that data

            Comment


            • #21
              If we are going to do a bunch of these we should talk about writing a quick app, looks like you guys spend almost as much time on the spreadsheet each as it would take to just build an app so we don't ever have to do it again.

              That's the lazy software guy coming out in me, I hate having to do the same task twice when I can automated it.

              Comment


              • #22
                Originally posted by Ken View Post
                If we are going to do a bunch of these we should talk about writing a quick app, looks like you guys spend almost as much time on the spreadsheet each as it would take to just build an app so we don't ever have to do it again.

                That's the lazy software guy coming out in me, I hate having to do the same task twice when I can automated it.
                While I'm not opposed to that, and while I certainly would do it differently given what I know now as opposed to what I knew 15 years ago when I built the first versions of this spreadsheet, I think most of the spreadsheet updates per se are relatively easy compared to the effort it would take to build an app. What's painful is the stats updates, which is always hampered by the fact that the most recent season usually isn't available on places like Retrosheet and the Lahman database until many months after the season ends, and places that do have the updates in a timely fashion, like B-R, require writing a scraper. I usually just query the MLBAM stats that I have available through work, but then it's a bit of a pain to integrate with the existing stats because of ID mapping.

                One other advantage of a spreadsheet is that it is accessible for maintenance by practically anyone, whereas custom queries and apps tie us to the designer more than we would like. I took a nine-year hiatus from vintage drafting, and my scoring spreadsheet is still alive and well in Johnny's hands.
                Last edited by Kevin Seitzer; 01-11-2019, 12:48 PM.
                "Jesus said to them, 'Truly I tell you, the tax collectors and the prostitutes are going into the kingdom of God ahead of you.'"

                Comment


                • #23
                  All this techno-babble is a transparent attempt to shake the confidence of us traditionalist drafters still using pencil and paper. It's not working. Heye, can I borrow your eraser ?
                  ---------------------------------------------
                  Champagne for breakfast and a Sherman in my hand !
                  ---------------------------------------------
                  The Party told you to reject the evidence of your eyes and ears. It was their final, most essential command.
                  George Orwell, 1984

                  Comment


                  • #24
                    Originally posted by Kevin Seitzer View Post
                    I think most of the spreadsheet updates per se are relatively easy compared to the effort it would take to build an app
                    It's possible you underestimate the app writing skills available to us (mjl, myself, possibly others?)

                    Originally posted by Kevin Seitzer View Post
                    places that do have the updates in a timely fashion, like B-R, require writing a scraper.
                    I wonder if the fact that I wrote a scraper in half an hour last night changes your answer?


                    Client code:
                    <script type="text/javascript" src="//widgets.sports-reference.com/wg.fcgi?css=1&site=br&url=%2Fleagues%2FMLB%2F<%=Re quest["year"] %>-appearances-fielding.shtml&div=div_players_players_appearances _fielding"></script>
                    <script>
                    var year = <%=Request["year"] %>;

                    $().ready(function () {
                    checkfordivs();
                    });

                    function checkfordivs() {
                    if ($("div").length > 0) {
                    var i = 1;
                    $(".full_table").each(function () {
                    var player = {};
                    player.playerid = $(this).find("td[data-stat='player']").attr("data-append-csv");
                    player.name = $(this).find("td[data-stat='player']").find("a").html();
                    player.age = $(this).find("td[data-stat='age']").html();
                    player.team_ID = $(this).find("td[data-stat='team_ID']").html();

                    .....

                    syncPostEx("SetFielder", JSON.stringify({ f: player }), function (msg) { });
                    i++;
                    });
                    year--;
                    if (year > 1870) { window.location.href = "Default2.aspx?year=" + year; }

                    service layer

                    [WebMethod]
                    public void SetFielder(fielder f)
                    {
                    using (var db = new DBCommand("Test.dbo.fielderyear_add"))
                    db.Add("@playerid", f.playerid)
                    .Add("@name", f.name)
                    .Add("@age", f.age)
                    .Add("@team_ID", f.team_ID)
                    .Add("@experience", f.experience)
                    .Add("@G_all", f.G_all)
                    .Add("@GS", f.GS)
                    .Add("@G_batting", f.G_batting)
                    .Add("@G_defense", f.G_defense)
                    .Add("@G_p_app", f.G_p_app)
                    .Add("@G_c", f.G_c)
                    .Add("@G_1b", f.G_1b)
                    .Add("@G_2b", f.G_2b)
                    .Add("@G_3b", f.G_3b)
                    .Add("@G_ss", f.G_ss)
                    .Add("@G_lf_app", f.G_lf_app)
                    .Add("@G_cf_app", f.G_cf_app)
                    .Add("@G_rf_app", f.G_rf_app)
                    .Add("@G_of_app", f.G_of_app)
                    .Add("@G_ph", f.G_ph)
                    .Add("@G_pr", f.G_pr)
                    .Add("@year", f.year)
                    .ExecuteNonQuery();
                    }
                    database code:

                    ALTER proc [dbo].[fielderyear_add] (
                    @playerid varchar(100),
                    @name varchar(100),
                    @age varchar(100),
                    @team_ID varchar(100),
                    @experience varchar(100),
                    @G_all varchar(100),
                    @GS varchar(100),
                    @G_batting varchar(100),
                    @G_defense varchar(100),
                    @G_p_app varchar(100),
                    @G_c varchar(100),
                    @G_1b varchar(100),
                    @G_2b varchar(100),
                    @G_3b varchar(100),
                    @G_ss varchar(100),
                    @G_lf_app varchar(100),
                    @G_cf_app varchar(100),
                    @G_rf_app varchar(100),
                    @G_of_app varchar(100),
                    @G_ph varchar(100),
                    @G_pr varchar(100),
                    @year varchar(100)
                    )
                    AS
                    BEGIN
                    insert into fielderyear
                    (
                    playerid,
                    name,
                    age,
                    team_ID,
                    experience,
                    G_all,
                    GS,
                    G_batting,
                    G_defense,
                    G_p_app,
                    G_c,
                    G_1b,
                    G_2b,
                    G_3b,
                    G_ss,
                    G_lf_app,
                    G_cf_app,
                    G_rf_app,
                    G_of_app,
                    G_ph,
                    G_pr,
                    year
                    )
                    select
                    @playerid,
                    @name,
                    @age,
                    @team_ID,
                    @experience,
                    @G_all,
                    @GS,
                    @G_batting,
                    @G_defense,
                    @G_p_app,
                    @G_c,
                    @G_1b,
                    @G_2b,
                    @G_3b,
                    @G_ss,
                    @G_lf_app,
                    @G_cf_app,
                    @G_rf_app,
                    @G_of_app,
                    @G_ph,
                    @G_pr,
                    @year
                    END
                    Originally posted by Kevin Seitzer View Post
                    I usually just query the MLBAM stats that I have available through work, but then it's a bit of a pain to integrate with the existing stats because of ID mapping.
                    Makes sense. But by going directly through the source we don't have that issue.


                    Originally posted by Kevin Seitzer View Post
                    One other advantage of a spreadsheet is that it is accessible for maintenance by practically anyone, whereas custom queries and apps tie us to the designer more than we would like. I took a nine-year hiatus from vintage drafting, and my scoring spreadsheet is still alive and well in Johnny's hands.
                    Another option is for me to build a quick app and expose a web query that anyone can pull in to any spreadsheet for the data...

                    Comment


                    • #25
                      Originally posted by Ken View Post
                      It's possible you underestimate the app writing skills available to us (mjl, myself, possibly others?)

                      I wonder if the fact that I wrote a scraper in half an hour last night changes your answer?
                      You're probably right. I think Scott wrote a BB-Ref scraper, too, which is how he got his data.

                      I know in the past there have been a few of us with database skills and some ability to hack some scripts together (Scott may have more of that than I do), but nobody who was really up to writing a full-fledged app and dealing with all the edge cases and support that would come with that. But I wasn't familiar with your background (or mjl's), so maybe I'm overestimating the difficulty. I work with people who know how to do what you do, but I don't know how to do it myself. Back in the day, a decade or more ago, some of us talked about building a web app to support this, and I was going to put my then-formidable (ha!) MySQL and PHP skills to work on that project. But it was always easier to just to roll the old spreadsheet over to a new draft.

                      It's really the new stats integration that's painful at this point with the spreadsheet.

                      Would you put the code in a github repo or something where it could be reviewed and built upon by others?

                      I think the ability to output a spreadsheet would be important so people could apply their own custom formulas and methods. Maybe that could be pulled into an app, too, but that would require people to disclose to you the types of valuation exercises they do, which they might not want to do.
                      "Jesus said to them, 'Truly I tell you, the tax collectors and the prostitutes are going into the kingdom of God ahead of you.'"

                      Comment


                      • #26
                        I know that Wayne - MJL and some others talked about some off site web page so we could get more people involved then just RJ and have more of these. Not sure where that went but an App would sound great. Of course I am no help . I am lucky just to open up, then unlock my computer.

                        Comment


                        • #27
                          I'm confident that we have a few fellows in the draft who could easily build a decent app ... but it depends on what you are planning on using this for? If it's just an online scoring sheet, then that'd be super simple. But we're planning on using this to draft, you'd need login privileges, security, enabling it to be set up for all draft types. All doable, but a lot harder and more time consuming than a simple online scoring sheet. Would there be copyright issues? Keeping it private for our usage only would help. But it's still a lot of work.

                          Then on top of that, you have issues of maintenance ... what if the designers decide to bail?

                          It'd be really cool, and i'd be a liar if I said I hadn't thought about it before, but it's a lot to ask.

                          Then again, if we have people willing to give it a shot, I'm all for it.

                          Comment


                          • #28
                            The bots still loving this sub forum

                            Comment


                            • #29
                              Originally posted by johnnya24 View Post
                              I'm confident that we have a few fellows in the draft who could easily build a decent app ... but it depends on what you are planning on using this for? If it's just an online scoring sheet, then that'd be super simple.
                              Iterative process. First, to host some stats that we can easily query. Then, to auto calc the scoring. Then, as data entry for the picks to make it easier (select name from dropdown, select year from dropdown).

                              Originally posted by johnnya24 View Post
                              But we're planning on using this to draft, you'd need login privileges, security, enabling it to be set up for all draft types.
                              Seems overstated. We're not protecting Ft. Hood here. Your login name is your email. Enter it in, and I can generate a password and send it to you, and then let you change it on your next time through the door. These are basic built in concepts these days.

                              If we had something financial it would be different.

                              As far as draft types, we store those in a config table, although there's not that much different from an app perspective.

                              Originally posted by johnnya24 View Post
                              All doable, but a lot harder and more time consuming than a simple online scoring sheet.
                              True except when we're dealing with having to manually fix problems on the spreadsheet every draft / every year

                              Originally posted by johnnya24 View Post
                              Would there be copyright issues? Keeping it private for our usage only would help. But it's still a lot of work.
                              No copyright issues, MLB names and data are not protected from use in fantasy, that case was decided. Keeping it private is easy.

                              Originally posted by johnnya24 View Post
                              Then on top of that, you have issues of maintenance ... what if the designers decide to bail?
                              Assuming we put the code on GitHub, no more of an issue than the designers of the relatively complicated spreadsheet I saw you going through before VD12!

                              Originally posted by johnnya24 View Post
                              It'd be really cool, and i'd be a liar if I said I hadn't thought about it before, but it's a lot to ask.

                              Then again, if we have people willing to give it a shot, I'm all for it.
                              If I have time I'll take a crack on starting on one, one of these days.

                              Comment


                              • #30
                                Originally posted by Ken View Post

                                If I have time I'll take a crack on starting on one, one of these days.
                                Web based? If so you can crack out the back end and leave the front to me. Or build a basic front, and I'll jazz it up.

                                Comment

                                Working...
                                X