ActivitiesAtom Feed

Displaying activities 1 - 25 of 59 in total

September 28, 2016

  • Tuesday, September 27th: Lunch and Learn at Pivotal

    Team Hackbrighters (Lektor CMS) [2016] — at September 28, 2016 22:59 UTC

    We continued brainstorming and poking at issue #245. We feel like we're a bit stuck, so we've reached out to Coach Gavin for support. He was going to come over to Github to help us debug, but he had something come up and wasn't able to help pair program with our team.

    Instead, we decided to have lunch at Pivotal Labs with Tim Jarrat. There was a very moving talk about mental illness in the workplace, and how tech companies can go about being more inclusive and accommodating of tech workers with disabilities. Afterwards, there was an Ally workshop with Valerie Aurora , co-founder of Double Union and Open-Source contributor to the Linux Kernel. The Ally workshop talked about how tech workers with privilege can use their privilege to counteract bias that marginalized groups face. It was extremely informative and eye-opening. Our team was also fortunate enough to thank Valerie for all of the work she has done to make tech, specifically the world of Open Source, a more welcoming place for people who may feel othered.

September 27, 2016

  • Sept 26th - Monday:

    Team Hackbrighters (Lektor CMS) [2016] — at September 27, 2016 05:48 UTC

    Today we started to tackle Lektor issue #245, error handling for file attachments with '@' symbol. There's a larger issue about how file attachments are handled by Lektor. A user can't change the file names currently, so the file IDs need to be valid. We'll try to tackle this last issue, but we have limited time with our coaches. We tracked down the files and functions that we need to debug via the traceback messages on two different issues filed about file attachments. This reminds us that when filing issues that we need to give as much information as possible to a maintainer. We hypothesize that we'll need to either make changes either to the or the files. The addattachment() function raises a Bad Edit error in the and is_valid_id() triggers a boolean value to check if an id name is in a valid format. -
    We're debating where to do the check for for invalid symbols. The error was raised in the database b/c the @ is reserved symbol for a virtual marker. The error should have been raised by a different function likely during the file attachment process. We think we'll need to add a validation screen in add_attachment() and use is_valid_id() to raise the error. We're hoping to consult with coach Gavin tomorrow, and maybe he can give us his expert opinion on this approach.

    We started to prioritize the tasks we need to get done before the end of our grand adventure. Fingers crossed that we get it all done!

September 23, 2016

  • Sept 23rd - Friday: Final Friday Retrospective

    Team Hackbrighters (Lektor CMS) [2016] — at September 23, 2016 23:45 UTC

    We spent most of the day troubleshooting our blog post on Github universe. Some of the pictures we resized in the Atom Editor came out pixelated. We went back the original picture for the ones that didn't quite come out right and re-scaled them in a dedicated image editor. We used GIMP because it's as powerful as Adobe Creative Suite (and because neither of us has a licensed copy). We also used a PNG file format as we figured the problems with images might be a limitation the JPEG compression format reacting weirdly with the backlighting that was common to the problematic pictures. We also needed to do attributions and captions for all the photos. So we had to rack our brain for the names of strangers and friends who helped us take pictures while we posed for them.

    We also combed for maybe a last issue that we could fix or feature we could implement for Lektor. We want to make at least one more substantial contribution to the project. We mulled over writing a contributor's guide for lektor's community that would might help ramp up a beginner to the project more easily, maybe doing a usability study with a non-technical user of Lektor, or maybe trying once again to write a test.

    We had our weekly check in with Andrea to talk as preparation for our final call-in with mentors and coaches tomorrow. We can't believe that this experience is winding down, and we're processing a lot of feelings about it. We agreed that we've come a long way, and we're pretty satisfied in the amount that we learned in such a short time. We're very thankful that we could have this journey!

  • Sept 22nd: Up, Up, and away!

    Team Hackbrighters (Lektor CMS) [2016] — at September 23, 2016 05:51 UTC

    Today we tried to make clean pull requests. We had started implementing a refactor of error handling in our git commit feature, and we wanted to make these two super clean commits. We telegraphed what we were doing in the issues log. So we had to pull out the new error handling code from the code where we started the new command line feature, and then we pushed a cleaner version of the commit to Github and then reopened the pull request. And then we filed the issue that coach Gavin had found earlier. He found that a malformed url in the project file threw up traceback error instead of "failing gracefully", as he put it. He had found this error earlier and offered an opinion on how to fix it. We had to table filing the bug and fixing it until we finished the git commit feature. However, there had been new code added that addressed a similar in an unusual place--the command line option file. He helped us re-think the fix so that raising a malformed url error would be generalizable enough so that we wouldn't have to do a url validation check in all the different types of Lektor deployment, as well as the command line. We found a way to do the error check in the publish function in the file. All the publishing / deployment targets touch that function, so that seemed the best place to raise the error instead of copying and pasting an raise PublishError function in multiple places. The easiest implementation of the error handling would've been to copy and paste, but to really thinking through the most efficient and most DRY (don't repeat yourself) approach was harder. And we're very lucky to have Gavin help us think through the problem like a computer scientist! A nice result of all this banging-of-head-against-wall was that we made two clean PRs that we're really proud of.

    We also worked on doing the blog post for the Rails Girls main blog. The pictures we took exceeded the recommended size, and we needed to get the size down to 600x600 or less. Instead of resizing them with a dedicated image editor or viewer, we used an atom editor package called image-resize where you can resize the pictures within the editor! Sublime will read images as binary files, but because atom is basically a chromium browser window with super powers, Atom can preview and manipulate images and animations. If you handle front-end web development, Atom editor seems to be text editor to beat.

    It also took a little while to work with Jekyll again. It's been a little while, so while we're much better with the Markdown language than the first time we posted a blog, building and previewing the pages took a little while. Jekyll was locking up while we were previewing changes, and we had to shut it down and restart preview a few times. It was hard to tell whether if Jekyll was crashing or the laptop we were running it off of. We'll happy to share our experiences at Github universe once we get this launched!

September 22, 2016

  • Wednesday, September 21st: Coach Gavin explains Inception Lektor and Our Brains Exploded

    Team Hackbrighters (Lektor CMS) [2016] — at September 22, 2016 11:32 UTC

    Before Coach Gavin paid Team Hackbrighters a visit at Github, our Team began printing a bust of the Greek statue Herkeles, on Github's 3D printer. The torso of Herkeles should be done sometime tomorrow.

    When Coach Gavin joined our team, we were struggling to re-create the scenario we had accomplished with Coach Ramil. We began diving deep into our development version of Lektor's virtualvenv, where we then believed to have found another on earth was this even possible?! This accidental discovery was so horrendously disturbing to us -- because we know it's not really possible to have a virtual environment within another virtual environment.

    We believe what had happened is that we had accidentally pip install lektor inside of an instance of pip install --editable .. We believe this happened because pip install lektor seems to be much more natural and intuitive of a command than pip install --editable . It's also interesting to note that there are no safeguards from this happening to other developers. Because of this interesting Lektor inception, we had to do a deep-search-dive into a venv in Lektor, and then hand compile with Coach Ramil on Monday, September 19th. This is what we did not entirely realize with Coach Ramil.

    After figuring out the mind-blowing Lektor inception, we attempted to create a beautiful pull request to finally implement the git commit --message CLI flag. We realized we had made a small syntax error, so we quickly utilized a git commit --amend to change the small error. Then, another error. We quickly realized we had accidentally added code we meant to be in another entirely separate commit that addresses another Lektor issue. We had made yet another mistake after we had just amended the pull request. At this point in time, it had grown to be very late, and Team Hackbrigthers was tired. We decided to just close our pull request and try again tomorrow, when we're more fresh and bright-eyed. We didn't want to risk making more mistakes due to being physically and mentally -exhausted.
    Stay tuned...!

  • Tuesday, September 20th - Open Source Panel at Hackbright Academy with Katrina Owen and Carol Smith

    Team Hackbrighters (Lektor CMS) [2016] — at September 22, 2016 00:09 UTC

    Team Hackbrighters was invited to speak at an Open Source panel hosted at Hackbright Academy, a software engineering school that trains women in software development and computer science. The panel included our team, in addition to GitHubbers Katrina Owen and Carol Smith.

    Katrina Owen, Developer Advocate at Github, is co-author of 99 Bottles of OOP with Sandy Metz, author of, and Project Maintainer for Sinatra. Carol Smith is currently the Education Partnership Manager at Github, and previously was the Google Summer of Code Program Manager, an online, international, philanthropic university outreach program that has served thousands of students. As Education Partnership Manager at Github, Carol oversees Github Classroom. GitHub Classroom automates repository creation and access control, making it easy for teachers to distribute starter code and collect assignments. Both Melissa and Patricia are alumna of Hackbright Academy, so our team feels a strong camaraderie with the current Hackbright students.

    The entire panel supports more women in tech, and agreed to giving our expertise and unique viewpoints on Open Source in order to create opportunities for fellow women early in their software engineering careers. We spoke to current students about the opportunities Team Hackbrighters have taken advantage of at Github as Rails Girls Summer of Code fellows. We gave the Hackbright students advice on how to break into tech via Open Source, by citing fellowships such as Google Summer of Code, Outreachy, and Rails Girls Summer of Code.

    Moreover, Melissa dived deep into her personal narrative of how she first began her coding journey and became interested in Open Source. She attended an Open Source Meetup, where Carol Smith was presenting a session on how to get-into the Google Summer of Code fellowship. Carol Smith highlighted that one does not have to be a traditional student enrolled at a four-year institution with a full-time course-load. All one has to do to fulfill the student requirement is to enroll in a swimming class at their local community college, and then drop said swimming class after one has proven they are a student.

    Also, the panel spoke about strategies on how to contribute to Open Source as a beginner. Our team gave advice on how to go about finding mentorship in the world of Open Source. Katrina Owen spoke about how to 'sneakily' find mentorship on Open Source projects. To explain, Katrina suggested that students help out overwhelmed and stressed Project Maintainers via closing out finished issues. By doing this, a student's Github handle reappears and is made familiar to Project Maintainers -- a student can create a rapport with Project Maintainers and the project's community, which then (hopefully) increases the likelihood of a student to successfully receive mentorship. Katrina advises this indirect strategy of asking for mentorship, rather than directly asking for someone to be a mentor. Rather than directly asking a senior developer for mentorship on a particular Open Source project, and risk overwhelming and overloading the senior developer with more responsibility.

    Furthermore, Carol Smith spoke about how problematic it is for supposedly begginer-friendly programming books are entrenched with math jargon. She strongly expressed how the fact that theoretical math is so deeply intertwined within programming education at the university-level is problematic, and is a large reason why women are pushed out of learning to code.

    Afterwards, Melissa taught part-time Hackbright Academy students, while Patricia mentored current full-time Hackbright students about Model-View-Controller.

September 21, 2016

  • Monday, September 19th - CLI Git Commit Message Breakthrough!

    Team Hackbrighters (Lektor CMS) [2016] — at September 21, 2016 23:33 UTC

    Team Hackbrighters had a very fruitful day! Albeit we had a very long, mentally-exhausting day, our Coach Ramil from LinkedIn helped unblock us on how to implement the Command-line Git Commit message on Lektor. Our team had been pouring over our Project Maintainer's library, Click. Click is a library that facilitates creating command-line interfaces in a succinct, easy-to-understand way. Specifically, our team focused on the Options API section of Click. After familiarizing ourselves with Click's interface, we implemented a --commit flag in in Lektor. We believed we had correctly constructed the necessary code, but we quickly realized couldn't even get our code to run. We inserted print statements in and we weren't even able to get the print statements to output to the terminal. We even inserted nonsense code in but we were unsuccessful in getting our code to fail where we expected it to fail. We realized that we weren't even running the code we were editing. How could this be possible? We showed this to Ramil, and he was also perplexed. He also agreed with our hypothesis that we weren't even running the correct code. With this at hand, Ramil gave us debugging tips. After examining the codebase, Ramil showed us that we had to actually had to go deep into Lektor development's virtualenv. We then had to hand compile the file. In order to accomplish this, Ramil showed us the command python py_compile! Ramil had showed us the Python Compile docs in order to accomplish this. After this magical incantation, we were finally able to get the Lektor development code we were editing to update and run! Hooray! Ramil advised us to ask the Lektor community about their development workflow; how do they develop on Lektor proper? The fact that it's so difficult and non-obvious how to run Lektor development code is an issue that should be better documented and explicated. There must be a better way to develop on Lektor's development codebase, rather than diving deep into Lektor's venv and hand-compiling single files to see its changes.
    Along the way, Ramil showed us useful bash commands, such as top. top shows you sorted information about processes on your computer. Ramil also showed uspushd and popd, which are Unix commands that allow us to manipulate the directory stack. These are handy commands for developers to efficiently jump around directories.

  • Sept 16th -Friday: In the after-glow of Github Universe.

    Team Hackbrighters (Lektor CMS) [2016] — at September 21, 2016 22:20 UTC

    Team Hackbrighters went back to the coding grindstone after the basking in glow of Github Universe. We picked up working on the git commit message feature upon deployment of a lecture build. We studied the documentation for the python click library that our project mentor wrote. It uses a lot of decorator patterns which we're generally unfamiliar with. We practiced using some of the code snippets from click's documentation to see how it worked. We still don't quite understand how decorators are used. And with click's library you can apparently stack many decorators on top of a single function for a single command because one command may have many options for it. We think we know how to use the click library and it's api, but we'll need someone to help us understand decorators patterns in general. They're supposed to be cool and amazing?

    We wrote a draft of the feature that should take in a command line flag --message and it should collect the string after the flag and then pass the string into the function. We implemented the road map that coach Gavin gave us and we think it should work. We talked through the code and tested simpler versions of the patter, but we can't seem to get the option to become activated from the command line. we've saved the file, and we've added print statements. However, when we try to deploy the test site from the command line, a lektor build and deploy actually occurs, but we can't see any of our test print statements. We'll keep working on this mysterious black hole of where are our git message going next week.

September 14, 2016

  • Sept 13th: Before the Big Bang

    Team Hackbrighters (Lektor CMS) [2016] — at September 14, 2016 19:40 UTC

    Team Hackbrighters had a great lunch appointment at Trulia's SF with Markis Taylor. He helped us think through common problems with working with legacy code especially with code that you don't have leave to change. Two common approaches are to write a "sprout class" that acts likes the original function instead of replacing it and then you build the rest of the code on top of the sprouted features. The drawback is that you'll have two branches of code that do similar things. Also you can write a 'wrapper class' that works with the current function but in a way that preserves the original function but change the functionality around the function.
    Markis called this technique working with the "seams" of a code base.

    We also worked on our git commit message feature. We studied the click wrote a draft of the the command line option feature and it looks like the command line is taking in the new message, but it fails when the message is being passed to the publish() function.
    The problem is that the git() function is nested within publish(). publish() takes in all the optional info (such as data passed via the command line) into the **extra parameter. However, python convention is not to nest functions. So we're not familiar with how data is passed from the outer function into the inner function. Some of the questions we asked coach Ramil was how to navigate this patter. Do we need to parse what's getting passed into extra, find our commit msg, and then pass that into the git() (which configures git upon a build/deploy). or is `extraalready getting passed in as part of the **kwargs` parameter that the git() function

    This past weekend we attended nodeschool oakland to learn node.js. Lektor also uses node, and maybe finally we're getting fluent in all parts of the Lektor's tech stack. We're saving a lot of energy for universe which looks like it'll be overwhelming, but we're ready for the challenge!

September 13, 2016

  • Sept 12th: Knowing when to fold 'em

    Team Hackbrighters (Lektor CMS) [2016] — at September 13, 2016 03:07 UTC

    After struggling with the Git workflow last week, Team Hackbrighters were privileged to sit in on a training session about using Git today. We had one-one lesson on Git with Github trainers Eric Hollenberry, Matt Desmond, and engineer Katrina Uychaco. We were actually serving as a test audience for their presentation at Github universe. Considering how that we lost code using a product that is supposed to archive code, we were grateful to have what Git does under the hood explained to us.

    While we're most comfortable with the basic Git incantations of git init, git add, git commit -m, Git is doing a lot under the hood. Git's underlying data structures are a tree as it saves commits, and pointers as it keeps track of where the HEAD refs are and identifies the different branches, as well as keep track of the references and branches of a remote origin branch. And on top of the that the Git workflow is itself a tree where one branch is the working directory where it keeps tract of of the working files after you git init, and then you're staging changes when you add files with git add, and then when you make the commit, your putting all the staged files in a snapshot/box and putting a date or time with it. They demo'd different teaching tools that they use with the classes they teach and one was a git visualizer that showed how commits are linked together in a parent-child tree structure and how the references can get moved around to the different commits. They taught us they you can only really lose data three ways, usually by changing the git history with commands such as git revert --hard and they showed us a live demonstration on how the working directory, staging, and commit branches stay updated with changes. It was really enlightening to have this insight into git, and this was just a sample of what's to come at Github Universe! We're so excited for the opportunity to learn more!

    We also had a meeting with Coach Gavin Crooks about moving forward with our git commit feature for Lektor. Now that we met the specs of our last code review, we're hoping to get at least a few more features aside from testing built. We also actually heard back from the maintainers of the pytest-plugins that were breaking, and they're proposing a minor release that would obviate our hotfix solutions and make our tests more robust. We had written a draft of the test we wanted to write for git commit, but we were stuck on how to pass the test commit message to the application. Gavin reviewed our code, and we poked around the Lektor codebase, and he concluded that writing a unittest for a git commit message given the way that Lektor currently handles git commit would be impossible. Lektor has a function that automatically publishes to Github Pages, as well as Githlab, and other production server configurations. and this function generates an empty temp directory within which a .git directory is also created, and git config file is automatically generated and then the whole lot--the all the built Lektor pages & the git directory-- is pushed to Github pages altogether. Gavin noted that these functions of creating the build and creating the git repository would have to be completely refactored so one isn't embedded in the other in order for the unit test to be testable. We would have to have some kind of dedicated gh-pages repository to deploy to just to test if a commit msg was added. He told us writing a full integration test that makes a call to an outside service would be too much trouble just to see if a short string was added to a full deployment. The test simply would be to see if commit message got added upon an actual deployment. While TDD is a useful ideology, if the lay of the land /codebase didn't support it, these efforts would by phyrric. We're glad to have our coaches' wisdom of experience to help us figure out when it's useful to walk away from a goal.

September 09, 2016

  • Sept 9th Friday: Git aftermath -- all isn't lost, just some...

    Team Hackbrighters (Lektor CMS) [2016] — at September 9, 2016 23:00 UTC

    So we walked into git rebase with our hearts pure and our minds clear, but little did we know we were walking into a minefield of git merge conflicts during rebasing. More on the gory details later...

    But we learned there are different philosophies around Git. Git is about saving your code from yourself sometimes, and other times, it's about creating the narrative of how a code base evolves and develops. Squashing commits is about keeping the commit log history clean where you only keep the major plot points and edit out the noise of "I changed x in y file" followed by "I changed x back b/c it didn't work". It's like cleaning out all the editorial margin notes in an essay to produce a final draft. The other philosophy is that the story of a codebase isn't found in the git commit logs but is better expressed in the pull requests. Github has a maintainer's tool that squashes commits from pull request branch upon merge. So they've automated git rebase for the website/web tool so, it's not quite on the onus of an open source contributer to face a rebase. The practice of squashing commits predates the social coding era of Github or Gitlab, but it's interesting to see that there may be a schism or an evolution about the process of a how a codebase documents its own narrative history.

    Meanwhile back at the ranch...
    The wed attempt at rebasing resulted in lots of git abort, and some files didn't make it through. We had to rebuild the code by doing a git revert and ultimately a git reset head. We still had all the logs and references so we rebuilt some of the errors that were left after the reset, and we then agreed on tackling the problem the next day. We enlisted our coach Seema to walk us step by step through the rebase. We did a google hangouts and had a great remote pair programming session. She was awesome to walk us through the valley of doubt that is git rebase -i. However, we didn't get far in the rebase because we had merge conflicts. We were working on was a branch of a branch, and there was extensive writing and rewriting of some files while we were trying to get the travis config files just right. If there's a merge conflict during a rebase you have to go into the files in the middle of the rebase, resolve the conflict and the git --continue or git --skip changes you're not particularly interested in. " Since the travis.yml file got edited back an forth so much we skipped a few the merge conflicts. We successfully did the rebase. Yay, right? However, what we didn't know is that we skipped some critical travis.yml changes, and they got squashed. We lost those logs. The tests ran locally again, but when we pushed the squashed files to github, travis ci was failing. We had lost the hotfix lines that made the build run which were bespoke solutions that coach Gavin Crooks helped us with before. And we couldn't get them back via git revert or reset because we had squashed, essentially deleted, those commits. There was some (maybe lots of) freaking out. However, our arch-nemesis of two weeks ago, Travis CI, comes to save the day b/c we could see the Travis logs of our previous successful build. We hunted back for a build that worked. Looked at the build log for deployment and then rebuilt the travis.yml file from the Travis CI logs. We, nevertheless, got the code back into a working state and ticked off the last task given to us in our code review notes. whew.

September 08, 2016

  • Wed Sept 7th: Can't see the forest for the branches

    Team Hackbrighters (Lektor CMS) [2016] — at September 8, 2016 03:19 UTC

    We worked on implementing a tmpdir fixture out of the pytest module that was suggested to us in our code review. We tried the suggested implementation, and all the tests broke. We'd never seen a wall of red error messages before and we'd never broken code we hadn't touched before either! We were really flustered about how changing the config fixture for one test sabotaged all the other tests. We studied a lot of documentation on how tmpdir works, and as well as the os modules (b/c tmpdir was supposed to replace forming an absolute filepath link that is generated to store screenshots when tests fail). We studied other test code that @singingwolf boy had committed to see how he implemented tmpdir. We made our changes based on how he wrote his files and we tried matching in his changes for his tests, and still left all our fixtures be. However, his changes for his tests (while leaving ours intact) still broke our tests.

    Some of our testing fixtures were very tricky to put together, and considering that not all the plugins work for the pytest, we reverted everything back to a working state and took a more conservative approach that doesn't fundamentally change how we setup our testing fixtures. The suggested change was supposed to make for a more 'elegant' solution, but we're happier with a solution that works but may be less 'pretty'.

    The last note from our code review was to squash the commits in our git log. We tried doing git rebase again but there's still something scary about git's black box magic. We tried it on our own and we either seemed to be in the wrong branch or too far back in the commit history (the branch we're making the pull request from is a branch off another branch) and we'd really hate to lose our hard-won working code. We asked a Githubber Patrick Nakajima to "hold our hand" while we tried to do the rebase. And spoiler alert: there's a squash commits option on Github! (it's a dropdown menu option after you make a pull request and it prompts you to merge the code) BUT only if you're merging branch into master. Since we don't have write access to Lektor's master branch and we can't do a pull request off our master branch because we'd be making a pull request off of the master codebase, we couldn't use this snazzy Github feature, dun, dun,...dun.. So he reverted us back to the command line. He taught us a neat command line trick with
    EDITOR="subl -w" git rebase -i <reallylonghashnumber> where we can open the rebase file with Sublime Text instead of Git's Nano editor, and the -w flag tells Sublime to wait for the rebase to run before closing. However, he actually ran into problems where we finally found the right commits to squash or commit, but it still didn't rebase properly. Githubbers actually don't squash commits as common practice and just leave the git logs noisy, so git rebase -i isn't second nature to him, but he was totally willing to "learn together". Guess what, he couldn't successfully complete the rebase either! It was pretty reassuring that the git pros still have trouble with the more complicated git maneuvers as well.

September 07, 2016

  • Github and Getting Closer to Git

    Team Hackbrighters (Lektor CMS) [2016] — at September 7, 2016 00:34 UTC

    Today our Team read documentation about the Pyopen constructor within the subprocess module. We're still not entirely sure about this powerful module.

    We also came across the term federated in terms of describing a database system. " A federated database is a system in which several databases appear to function as a single entity. Each component database in the system is completely self-sustained and functional. When an application queries the federated database, the system figures out which of its component databases contains the data being requested and passes the request to it. "

    We also looked up what .gitkeep is. We came across this "Git cannot add a completely empty directory. People who want to track empty directories in Git have created the convention of putting files called “.gitkeep” in these directories. The file could be called anything; Git assigns no special significance to this name.".

    Our team read up on Pytest documentation, and were debugging how to go about getting stndoutput to print to the terminal. Pytest usually doesn't print output to the terminal, unless a particular test is failing. Since all of our tests were passing, but we still wanted to see a particular output, we researched and came across the -s flag; this flag shows print statements in the terminal. We added this flag to our make file.

    Our team continued to experiment with implementing a test in We experimented with including regex , but we're kind of at a loss and are stuck. We'll continue poking at this tomorrow.

    We got feedback on our pull request from @singingwolfboy. He gave us a wonderful code review, and we implemented the changes he suggested into our pull request. We've successfully added the changes, and they passed on Travis CI!

September 06, 2016

  • Friday, September 2nd:

    Team Hackbrighters (Lektor CMS) [2016] — at September 6, 2016 19:23 UTC

    With our roadmap in hand from Coach Gavin about implementing a Git Commit Message on the Command Line, we began to write our test. This is our first true attempt of Test-Driven Development. Our first major challenge was where exactly to put the test in the codebase. Secondly, we needed to figure out what our tests needed to run.
    We knew we needed a server, because Lektor can only do the commit upon deploy. Our first attempt was to put it in After thinking about it, speaking with Coach Ramil, and doing more research, we identified as the file that controls the git environment, specifically with the class GithubPagesPublisher(Publisher). We realized this test would fit better in because we're building out a feature that only gets executed upon deploying a Lektor project. Our team did an immense amount of code spelunking to figure out how to get the method update_git_config() to run in We studied the other deployment tests, as well, to begin fleshing out our own test.

    Our team also researched git hooks to see if we could take advantage of any specialized git functions. We learned that git hooks customize git functions like git commit or git push. We found out we didn't need them for our purposes, but they were a fascinating topic nonetheless. We were surprised how customizable git can be.

    We found a more elegant solution. We figured out to manipulate the .git/config by writing directly to .git/logs/HEAD. We had to first build the path with the .mkdir() method from importing python's os module. Through this entire fellowship, our team has been really exposed to Python's os, shutils modules.

September 02, 2016

  • Hacking Ourselves and the Lektor Bot

    Team Hackbrighters (Lektor CMS) [2016] — at September 2, 2016 01:48 UTC

    Today, Team Hackbrighters attempted to deploy a Lektor build to Github pages all of the day. We did this in order to try to add a a Command Line interface to deploy Lektor from. In order to successfully see this feature through, we need a test server to deploy from. All day, we've been really struggling with deploying a Lektor project via Github pages. Our team has scoured through the Lektor docs....we somehow ended up having a lektor-bot deleting all of our code, as seen here: How bizarre that lektor-bot just deleted all of our code, instead of publishing it...

    In spite of all of this, we tried again, and successfully got Lektor to deploy onto Github pages! Success! We believe it was because we manually pushed to our gh-pages branch, and this confused the code. Instead of manually pushing to our gh-pages branch, we made sure to do lektor build && lektor deploy off of master branch, and that seemed to have worked like a charm. Through our struggles, we've also discovered an interesting bug in Lektor!

September 01, 2016

  • Meeting with Coach Gavin - Gameplan for Custom Commit Message to Lektor

    Team Hackbrighters (Lektor CMS) [2016] — at September 1, 2016 00:00 UTC

    Today our team met with our Coach Gavin, and we created the following outline on how to go about implementing the Custom Git Commit Message on Lektor's User Interface:

    In, after line 242, add a new command option, something like

    @click.option('-m', '--message', type=????, default=None,
    help='Custom commit message (or something)')

    Option names should be same as git, -m and --message.
    (We're still confused about envvar. They are used here to set the password and username from the environment. We don't need them.)

    At line 291, pass the message to publish

    event_iter = publish(env,, output_path,

    This does not require a change in publish() (in line 657)
    because publish is defined with **extra key word arguments! Which are automatically passed through to the publisher.

    In the github publisher, around line 636, we should grab the message from the optional keyword arguments. Something like...

    default_message = 'Synchronized build'
    message = extra.get('message', default_message)

    Then add custom message to git commit line.
    for line in git(['commit', '-qm', message]):

    We should test everything, and try to create a cohesive unit test.

    Our team is extremely excited to have an actual draft of what our next steps are!

August 31, 2016

  • How the Internet Works, Posixpath, and the Future of Github

    Team Hackbrighters (Lektor CMS) [2016] — at August 31, 2016 00:06 UTC

    Our morning began with an All Hands company-wide meeting, where Githubbers from all departments came together to hear company-wide news, in addition to listen to defunkt speak about the future health of Github as a company. It was very intriguing to listen to defunkt's musings about Github's so-called plan for mainstream world-domination. Our team was particularly intrigued by Github Education's products and expansion. Github would like to become a website where people learn to code, similar to Codecademy. Furthermore, Github would love to utilize code that it hosts, and take advantage of machine learning AI to aid developers in writing code. Defunkt's long-term goals for Github include fleshing out a machine-learning algorithm to suggest vulnerabilities in developer's code, or suggest solutions to bugs in code.

    Today Team Hackbrighters went over How the Internet Works! Github was experiencing wifi troubles, so we were inspired to look deeper into how exactly the internet works. It's a resource that we take for granted, in addition to a popular interview question asking of software developers during technical interviews.

    Team Hackbrighters explored the topic of Internet Protocol (IP addresses). In essence, every router keeps track of multiple paths for sending packets, We learned that having multiple options for paths makes networks fault tolerant and reliable. Moreover, our team went over how Transmission Control Protocol (TCP) manages the sending and receiving of all your data as packets. When your packets of data arrive, TCP does a full inventory and sends back acknowledgements of each packet received. If all packets are there and are accounted for, TCP signs for your packets and for example, your media file will be played. For example, Hotline Bling by Drake is played. Otherwise, if not all packets are accounted for, TCP won't sign. Packets then will be re-sent and Hotline Bling won't be played until all parts of the song is accounted for.

    Specifically, in terms of Lektor, we studied the codebase more. Specifically, continued studying publisher.pyin order to begin to add a Git Commit comment feature on Lektor's User Interface. We specifically asked @singingwolfboy and @mitsuhiko on where they thought it was best to add the code for the Git Commit Comment feature (Issue #197). We also read documentation for theposixpath module, which is used in Our team believes it somewhat understands what accomplishes. We think this file essentially opens up the user's shell, and edits the user's .git/config file as the user hits the publish button on Lektor. We believe we may have to inject our own code at this point in order to implement the github commit comment feature.

August 30, 2016

  • Aug 29th, Monday: Recovering React

    Team Hackbrighters (Lektor CMS) [2016] — at August 30, 2016 02:24 UTC

    We made some tweaks to our integration testing branch, and we got the confirmation to make the pull request to the Lektor's master branch. We didn't think we'd spend so long sorting out testing. With test driven development, developers often think about what is testable first and then develop the product. We learned first-hand that setting up a testing an integrated testing procedure after the application's been developed is much harder than it appears. Working on testing isn't just "Let's write some tests"; writing the tests might be the easy part. You have to work out how the tests are going to run the application, and then you have to tool your testing environment so the tests have a place to run. Improving test coverage for us meant running shell commands, diving deep into the backwaters of python modules, and creating a working development environment on linux. This was definitely a learning adventure that wasn't expected, but we're glad to have learned all the new tools and commands that we picked to survive it.

    Now that we established a testing platform for integration testing, we starting moving back toward building a feature. Specifically, we pinged our project mentor about building a git commit feature that was requested by the Lektor community. Ideally the the feature would take in a commit message from the web ui, and then take the message to the git logs. We anticipate that this feature will be using react so we picked up where we left off in our React tutorials, and re-familiarized ourselves with jsx , es6 style javascript, and webpack.

August 29, 2016

  • Aug 27th: Skipping Along

    Team Hackbrighters (Lektor CMS) [2016] — at August 29, 2016 04:14 UTC

    We got feedback on our Travis CI hotfix hack. The Travis CI test environment builds properly for python 2.7 and python 3.5 (whew!), but Lektor's python 3 specialist diagnosed the pytest plugin eco-system as "too many levels of broken on Python 3". We had solved the python 3 test failures by disabling the py3 environment on Travis. But @singingwolfboy taught us a better way to punt the Python 3 problem. Pytest has a skipif decorator where we can specify the single test to run only if it's in a python 2.7 environment and the test will be skipped under a python 3 build.

    We made the changes to the one integration test that was giving us problems (to be fair it's a complicated test that tries to spin up a server to run lektor and push the built pages to another server) and the right test was skipped. With that test being skipped we finally know that our second integration test passed for sure-- under py2.7 and 3.5, which weirdly proves that the pytest plugins we were using are not completely broken under py3.5. So while that mystery remains, we were given the green light to move on to other tasks. So we're waiting to hear if we can make a pull request to the main code base from this branch. We had to dig deep and untangle really specific lines of code, but we finally have a completely passing build on Travis for our integration tests. Finally!

August 26, 2016

  • Github Education and Exploring Pyenv

    Team Hackbrighters (Lektor CMS) [2016] — at August 26, 2016 00:39 UTC

    Today we had a surprise visit from our Career advisors from Hackbright Academy, Wendy Sacuzzo and Ximena Cervantes. They were having lunch with a fellow Githubber, Carol Smith, who is a Program Manager for Github Education. It was a wonderful surprise to meetup with old friends! In the process of doing so, we had made a new connection, Carol Smith. Our team had an impromptu meeting and spoke to Carol about our experiences breaking into the tech industry with experience in the humanities. Carol is spearheading an apprenticeship program at Github, so she sought our input as current Open Source fellows. Her and her team will contact us in the future so that we can strategize how to best implement an apprenticeship program at Github! How exciting!

    Moreover, Team Hackbrighters explored many avenues on how to go about installing Python 3 on our local development environments. We explored the avenue of having Python 3 live within a virtual environment within our laptops. We quickly experimented with having a virtualenvironment within We're also familiar with rbenv and rvm in the Ruby world, as well as nvm in the Node world. We did a google search and found this tool called pyenv. We've been exploring pyenv and have been trying to install it on our local machines, and it has been an interesting challenge.

  • Aug 24th Wedensday: Curiouser and curiouser....

    Team Hackbrighters (Lektor CMS) [2016] — at August 26, 2016 00:14 UTC

    Team Hackbrighters' latest Lektor mystery has been how to get our tests to run in Python 3. We finally got the hang of configuring Travis CI to install the dev environment needed to run out tests, but the build kept hanging when Travis tried to install the necessary modules under python 3. After some splunking into pytest docs, we learned a lot of pytest-plugins don't work with pytest 3.0. We first tried to change the travis.yml from updating pytest to simply installing pytest. But alas....

    Luckily for us, coach Gavin paid us a visit because he happened to be running errands in SF. He helped us hunt down the exact line that was failing in the plugin package. We tried installing different versions of pytest, and he showed us how to do a text substitution using the unix command sed -i /<line you want to change>/<new text./the-file-path-where-that-line-of-code-lives . With this line, the text substitution happens at runtime. A hotfix solution was our only way to resolve the problem with the problematic plugins because the github repository from whence they came wasn't setup to be install directly via git. The python 3 error we were throwing has actually been fixed in the github, but that version is not the version that lives on PyPi, where most python modules are made available for the python community. The hotfix won't be needed as soon as the new release of pytest-plugins gets released via pip install.

    As much as we wished that these hotfixes were the only magic incantations we needed, but alas...

    With our hotfix, all the still tests pass in Travis CI's python 2.7 environment, but py3 still fails. However, it fails but not because the modules don't install. Rather the modal popup box that confirms the pages were published fails. We're not exactly sure if we caught a legit error with lektor failing to publish under py3.5 or that the pytest-splinter plugin that we're using to drive the browser for our tests is failing. According to the pytest-plugin compatibility chart that we linked to, pytest-splinter is not compatible any version of python under pytest 2.9 or 3.0. But pytest-splinter in fact works for us in python 2.7 using both pytest 2.9 and 3.0. Curiouser and curiouser, yes?

August 23, 2016

  • August 23rd: Experimental Travis CI Alpha tools and

    Team Hackbrighters (Lektor CMS) [2016] — at August 23, 2016 23:33 UTC

    This morning we returned to Exercism katas; Team Hackbrighters was excited to jump back into the world of katas, since we had somewhat paused our kata-learning these past few weeks due to deeply exploring Travis and the challenges it posed. For our daily kata, we went over an intriguing pangram challenge. We learned about Ruby's .gsub regex method, the .uniq method (which is similar to Python's set method), in addition to Ruby's .scan regex method. We found out that if you'd like to scan a string for alphabetic characters (including alphabetic characters with accents and special punctuation), you can use .scan(/[[:alpha:]]/) and it will be inclusive of those 'weird' characters. We also learned about how you can quickly call ("a".."z").to_a if you need an alphabet in a jiffy in Ruby! Lastly, we explored how .freeze makes something immutable. This is particularly useful for constants that you want to make sure is not changed.

    Furthermore, we learned more git commands. We learned how to branch off of a branch. You do this by git checkout -b myNewFeatureBranch originalBranch. As time goes on, our team keeps being reminded how complicated git truly can be.

    Today we are exploring and poking at Travis CI's Alpha debugging tools so as to attempt to better configure Lektor's .travis.yml file. We emailed Travis CI support this morning, and received instructions both for triggering than sshing into debug build for a open source project. Currently we're exploring their instructions.