【Hacker News搬运】我们开发软件的算法

[hackernews]

Title: Algorithms We Develop Software By

我们开发软件的算法

Text:

hn link

Url: https://grantslatton.com/software-pathfinding#algorithms-we-develop-software-by

由于我是一个文本和信息处理模型，无法直接访问外部网站内容。不过，我可以指导你如何使用JinaReader或其他类似工具来抓取和分析网页内容，并总结信息。

以下是一个假设的步骤，描述了如何使用JinaReader或类似的工具来抓取和分析网页内容，并将非中文内容翻译成中文：

1. **安装和设置JinaReader**：
   - 首先，确保你已经安装了JinaReader，并按照其文档设置好了环境。

2. **抓取网页内容**：
   - 使用JinaReader的API或命令行工具，输入你提供的URL（https://grantslatton.com/software-pathfinding#algorithms-we-develop-software-by）。
   - JinaReader将会爬取该网页，并提取出所有的文本内容。

3. **内容分析**：
   - 使用JinaReader内置的自然语言处理（NLP）功能，对抓取到的内容进行分析。
   - 这可能包括提取关键词、主题、实体识别等。

4. **翻译非中文内容**：
   - 如果网页内容包含非中文内容，可以使用JinaReader的翻译功能，或者集成一个第三方翻译API（如Google Translate API）来翻译成中文。
   - 确保你遵守相关的API使用条款和版权法律。

5. **总结内容**：
   - 使用JinaReader的总结功能或手动编写总结。
   - 根据抓取和翻译后的内容，提炼出主要观点、关键信息或文章的目的。

以下是一个简化的示例代码，假设使用JinaReader和Google Translate API：

```python
from jina import Document, Client
from googletrans import Translator

# 创建JinaReader客户端
client = Client()

# 抓取网页内容
response = client.post('/index', inputs=['https://grantslatton.com/software-pathfinding#algorithms-we-develop-software-by'])

# 翻译非中文内容
translator = Translator()
for doc in response:
    if not doc.text.startswith('中文'):
        translated_text = translator.translate(doc.text, dest='zh-cn').text
        doc.text = translated_text

# 分析和总结内容
# 这里可以添加自定义的分析和总结逻辑

# 输出总结结果
print("内容总结：", response[0].text)

请注意，上述代码是一个简化的示例，实际使用中需要根据JinaReader和Google Translate API的具体实现来调整。

        
## Post by: ksec
        
### Comments: 
        
**declan_roberts**: &gt; <i>A piece of advice I&#x27;ve given junior engineers is to write everything twice. Solve the problem. Stash your code onto a branch. Then write all the code again. I discovered this method by accident after the laptop containing a few days of work died. Rewriting the solution only took 25% the time as the initial implementation, and the result was much better.</i><p>This is true, and I&#x27;ve discovered it myself by losing a branch.<p>However, who the hell has time to write everything twice? There&#x27;s 1,000 things waiting to be written <i>once</i>.
> **declan_roberts**: &gt<i> 给我一条建议；我给初级工程师的建议是把所有东西都写两遍。解决问题。将代码存放在分支上。然后重新编写所有代码。我偶然发现了这种方法，因为装有几天工作的笔记本电脑坏了。重写解决方案只花费了初始实现的25%的时间，结果要好得多</i> <p>这是真的，我；我自己丢了一根树枝才发现的<p> 然而，谁有时间把所有东西都写两遍呢？那里；有1000件事等着<i>写一次</i>。
            
**w10-1**: People learn to work better by reflecting on work.  So any framework for self-observation is better than none.<p>I suspect that algorithms as a framework demonstrates the structural aspects (e.g., how some searches are more extensive), but might hide the driving factors. Indeed, the article examples were almost all hacking personality, not technical or process solutions.<p>E.g., most over-engineered solutions are driven by fear, often itself driven by critical or competitive environments.  Conversely, much of the power of senior&#x2F;staff engineers comes from the license to cut corners afforded their experience.  Or people use the tools they know.<p>You can&#x27;t get to great by holding onto good.  It&#x27;s easy to go from bad to good, but takes some courage to toss good to start over for great.  The lesson there is that we stand (hide?) behind our work, and we need to let go of it to improve it.<p>A meta-lesson is that managers need to deeply understand personal space of each developer and the social dynamics of the team before they can do their job effectively, and a key part of that is likely checking in with developers in a way that enhances their courage and self-observation instead of making them fearful and paranoid.
> **w10-1**: 人们通过反思工作来学会更好地工作。因此，任何自我观察的框架都比没有好<p> 我怀疑算法作为一个框架展示了结构方面（例如，一些搜索是如何更广泛的），但可能隐藏了驱动因素。事实上，文章中的例子几乎都是黑客个性，而不是技术或流程解决方案<p> 例如，大多数过度设计的解决方案都是由恐惧驱动的，而恐惧本身往往是由关键或竞争环境驱动的。相反，老年人的大部分权力；员工工程师从执照上偷工减料，为他们提供了经验。或者人们使用他们知道的工具<p> 您可以；坚持好不会变得伟大。它；从坏到好很容易，但需要一些勇气来抛弃好，重新开始。这里的教训是，我们站在（隐藏？）我们的工作背后，我们需要放手来改进它。一个元教训是，管理者需要深入了解每个开发人员的个人空间和团队的社会动态，才能有效地完成工作，其中一个关键部分可能是以一种增强他们的勇气和自我观察的方式与开发人员沟通，而不是让他们感到恐惧和偏执。
            
**MillironX**: I fundamentally disagree with the &quot;gun to the head&quot; strategy.<p>One of the major projects I worked on was a virus genome analysis pipeline. Our initial funding was for single-segment virus analysis, but about a year into the project, our grant collaborators needed to demonstrate multi-segment virus support within two weeks. My PI and I agreed on a quick and dirty method that would produce the analyses needed and could be done in the allotted time. That piece of code was fundamental to how the whole pipeline worked, however, and so as the pipeline grew, it took on the shape of the &quot;gun to the head&quot; decision we had made to the point where other, more essential features of the pipeline had to be delayed so I could come up with more workarounds.<p>There were clearly other issues at play here (scope creep and lack of separation of concerns were huge). My time at the lab came to a close, but if I were to have a chance to continue that project, I would start over from scratch rather than deal with the baggage that that one &quot;gun to the head&quot; moment created.<p>I understand that it&#x27;s a heuristic and not meant to be taken as 100% truth for every situation. I also understand that it&#x27;s trying to avoid that &quot;paralysis by analysis&quot; that&#x27;s so easy to fall into. I just question how useful it truly is as a heuristic, especially since it seems to go against the &quot;write everything twice&quot; algorithms presented in the rest of the piece.
> **MillironX**: 我根本不同意&quot；枪口对准头部&quot；战略<p> 我参与的一个主要项目是病毒基因组分析管道。我们最初的资金用于单片段病毒分析，但在项目进行约一年后，我们的资助合作者需要在两周内证明多片段病毒支持。我和我的PI就一种快速而肮脏的方法达成了一致，这种方法可以在规定的时间内进行所需的分析。然而，这段代码对整个管道的工作方式至关重要，因此随着管道的发展，它呈现出&quot；枪口对准头部&quot；我们做出的决定已经到了必须推迟管道其他更重要功能的地步，这样我才能想出更多的解决方法<p> 这里显然还有其他问题在起作用（范围蔓延和缺乏关注点分离是巨大的）。我在实验室的时间即将结束，但如果我有机会继续这个项目，我会从头开始，而不是处理那个项目的包袱；枪口对准头部&quot；创造的时刻<p> 我明白；这是一种启发式方法，并不意味着在每种情况下都是100%正确的。我也明白；我们正努力避免这种情况；分析瘫痪&quot；即；很容易陷入其中。我只是质疑它作为一种启发究竟有多有用，特别是因为它似乎与&quot；每件事都写两遍&quot；本文其余部分介绍了算法。
            
**neilv**: These are useful mental tools, to have in your mental toolbox, and apply them as they seem appropriate, but don&#x27;t make a religion of any of them.<p>A related old idea about writing&#x2F;reworking software <i>three</i> times: &quot;Do it.  Do it right.  Do it fast.&quot;<p>Startups provide ample opportunities to get experience with what the article calls &quot;gun to your head heuristic&quot;.  You have to decide what and how to compromise.<p>And, if you want your startup to be successful (not just hit your metrics&#x2F;appearances, and then job hop), you can&#x27;t just do it like school homework (where the only goal is to slip something past a grader, and forget about it), but you have to creatively come up with a holistically good compromise solution, given all the factors.  If you do this well, it&#x27;s creative magic that can&#x27;t be taught, but can be learned, through experience and will.
> **neilv**: 这些都是有用的心理工具，可以放在你的心理工具箱里，并在适当的时候应用它们，但不要；不要把他们当成宗教<p> 关于写作的一个相关的旧想法；对软件进行三次</i>返工：“；做吧，做对了。快点&“<p> 初创企业提供了充分的机会来获得文章所称的经验&quot；用枪指着你的头的启发式方法&quot；。你必须决定妥协什么以及如何妥协<p> 而且，如果你想让你的初创公司取得成功（而不仅仅是达到你的指标，然后跳槽），你可以；不要像做学校作业那样做（唯一的目标是把某件事交给评分员，然后忘记它），但考虑到所有因素，你必须创造性地提出一个整体上好的折衷解决方案。如果你做得好，它；这是一种创造性的魔力，可以；不能教，但可以通过经验和意志来学习。
            
**OutOfHere**: It is the worst advice I have read. If the goal is to divide everything to fit in a day, it would be better to use a static analyzer to enforce certain rules.
> **OutOfHere**: 这是我读过的最糟糕的建议。如果目标是划分所有内容以适应一天，那么最好使用静态分析器来执行某些规则。