每个月我们都会问你,你也会告诉我们,你的硬盘里有什么。很高兴看到所展示工具的广泛性:一些是专有的,一些是开源的;一些来自软件市场的大型厂商,另一些来自小型商店或开发者群体。但不知何故,它们都共存(尽管不一定和平共处),满足了从这里到廷巴克图开发者的各种需求。见证对任何一个产品的观点多样性也很有趣。不幸的是,我们只能在本页展示这些观点的片段,所以请访问 http://www.acmqueue.com 阅读更多内容,并对你对这些工具的看法发表意见。
人物: Andrew Marshall
所属行业:软件工程
地点: 加拿大,新斯科舍省,金斯顿
方向: 基于Windows Embedded开发
我喜欢的工具!GCC。我喜欢GCC,因为它的每个编译器都完全按照指示执行——不多也不少。如果你不能在不使用IDE的情况下用你喜欢的语言编写程序,你就不是程序员。
我讨厌的工具!BlueJ。使用IDE是一件坏事;然而,BlueJ设法让它变得更糟。我可以理解一个想要使其更像命令行编程的IDE,但这个IDE没有击中目标。
人物: Terry Shikano
所属行业:软件工程
地点: 美国,佐治亚州,亚特兰大
方向: 基于Windows/Linux为Windows/Linux开发
我喜欢的工具!Vi。它紧凑且启动速度快。我几乎将Vi用于所有事情,从脚本编写到C/C++到Java。它从不让我失望,除非我需要使用Lisp(然后我切换到Emacs)。
我讨厌的工具!Eclipse。它有太多的功能,其中一些功能不稳定。而且,它很慢。我花在诊断这个IDE问题上的时间比编写实际代码的时间还多。
人物: Jim Adams
所属行业:软件工程
地点: 加拿大,新不伦瑞克省,弗雷德里克顿
方向:基于Windows为Windows开发
我喜欢的工具!Eclipse 4.0。Eclipse是一个强大的Java开发环境,它拥有构建大型应用程序所需的所有功能。它有一个类似于Visual Studio的Intellisense的功能,可以在输入时显示类和方法信息。并且它保持我的代码已编译,所以我只需要运行应用程序。
我讨厌的工具!NetBeans 4.0。虽然功能良好,但该工具加载速度慢,使用起来也很迟缓。有太多的选项和组件需要加载和使用。应该有一个可配置的加载过程,以最大限度地减少加载时间和缓存使用。
人物: James Blackwell
所属行业:软件工程
地点: 美国,宾夕法尼亚州,威尔克斯-巴里
方向: 基于Linux为Posix开发
我喜欢的工具!Meld。我经常审查其他开发人员的代码,寻找接口更改,解决冲突等。使用Meld,我可以轻松比较两个工作树之间的差异,以清晰直观的方式呈现。
我讨厌的工具!Bugzilla。虽然Bugzilla是一个非常强大的工具,但与像Bugzilla这样设计糟糕的以Web为中心的界面交互几个小时后,常常会让我偏头痛。自由软件社区可以使用多协议的错误跟踪器。想象一下,通过telnet连接到错误跟踪系统,并使用类似SQL的界面搜索错误,通过电子邮件关闭错误,或者使用NNTP界面,该界面可以提供按各种层次结构排序的错误线程视图。
最初发表于Queue 第3卷,第3期—
在数字图书馆评论本文
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在,但在它们的设计方式上似乎存在差距。出于各种安全要求的考虑,存在许多用于加密哈希的标准,但在非加密方面,存在一定程度的民间传说,尽管哈希函数历史悠久,但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义,但当面对具有特定模式的数据集时,这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx实践
DevEx(开发者体验)在许多软件组织中越来越受到关注,因为领导者们希望在财政紧缩和人工智能等变革性技术的背景下优化软件交付。直观地看,技术领导者普遍认为,良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而,在许多组织中,改善DevEx的拟议举措和投资难以获得支持,因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极低代码技术进行的实验室实验结果来提供关于该主题的新见解,以研究生产力方面的差异。低代码技术已清楚地显示出更高的生产力水平,为低代码在短期/中期内主导软件开发主流提供了有力的论据。本文报告了程序和协议、结果、局限性以及未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界,新的工具、技术和技巧不断被开发出来以服务于商业和社会,但它也很健忘。在它快速前进的匆忙中,它容易受到时尚的支配,并且可能会忘记或忽略一些它面临的永恒问题的成熟解决方案。用例,最早于1986年引入并在后来普及,就是这些成熟的解决方案之一。