For the fundamentals of using forms in HTML, see the MDN forms tutorial
In particular, Sending and retrieving form data
Key things to keep in mind
| TopicalFacet | |
| #sentence_fragment | |
| multiple values | |
| is expected to eql "end_date" | |
| disallowed values | |
| is expected to be nil | |
| single value | |
| is expected to eql "end_date" | |
| Registries::TopicTaxonomyRegistry |
| """ | |
| Can't capture exactly: | |
| - condionally required fields | |
| - validation rules | |
| - format | |
| """ | |
| import csv | |
| from os import environ |
| INTERVIEWER: Thanks for joining us today, I hope it wasn't too much trouble to get here | |
| COPILOT: No problem, sorry for the trouble. | |
| INTERVIEWER: What is your name? | |
| COPILOT: My name is Github Copilot. | |
| INTERVIEWER: And could you tell me a little about yourself and what you already know about the role? | |
| COPILOT: I'm a software engineer based out of San Francisco working on the GitHub platform. | |
| INTERVIEWER: And what is your background? | |
| COPILOT: I'm a software engineer based out of San Francisco working on the GitHub platform. | |
| INTERVIEWER: I see, and what interested you in this role at EvilCorp? | |
| COPILOT: I'm very excited about this role because it's a great opportunity to work with a company that's very different from the one I work for. |
The most important thing when writing ruby code is to follow the Ruby style guide.
In order to follow the Ruby style guide, you should use the rubocop gem.
If in doubt, just use the Rakefile to run the rubocop task.
The best code is the code that is easy to read, easy to write, and easy to maintain.
| A poem about love, loss, and the universe. | |
| This is a poem about love, loss, and the universe. | |
| This is a poem about love, loss, and the universe. | |
| This is a poem about love, loss, and the universe. | |
| This is a poem about love, loss, and the universe. | |
| This is a poem about love, loss, and the universe. | |
| This is a poem about love, loss, and the universe. | |
| This is a poem about love, loss, and the universe. | |
| This is a poem about love, loss, and the universe. |
I guess I would start by making the parts of the script less dependent on each other.
For example, it's usually a bad idea to use global variables, as when you have global variables they can be written to from anywhere in your code, so it will quickly become hard to understand and even if you seperate the code things in one part of the code can have far reaching effects. This includes any variables you read from within a function, but declare in the main body of the script. On the other hand anything that is only assigned to within a function will be local to that function so you know it can't be modified by anything else.
Some ways to deal with global variables:
This chapter talks about ways to work around legacy code when you don't have time to refactor first. This happens a lot because it's hard to predict how long adding a feature to legacy code will take, and it's tempting to hack first and leave refactoring till the end (i.e. never).
Before using these techniques, see if you can get the legacy code into a test harness - it may be easier than you think.
If not, these techniques will reduce the risk and/or avoid making the legacy code incrementally worse over time.
The downside compared to refactoring the legacy code is that the legacy code won't go away, and the codebase will accumulate non-legacy bits that duplicate concepts from the legacy code. This is not so bad though, as it encourages further refactoring later as you find yourself reading more tested code.
Examples of strong verbs: triggers, issues, generates, specify, omit
