现场音乐发烧友又是一年中的那个时候。 夏季音乐节阵容正在放缓。 您还记得自去年夏天以来您还没有打扫过帐篷； 在不同的活动中有不同的喜爱艺术家的混合感觉，您仍然没有弄清楚哪个假期适合您的假期预算。
好吧，至少那是我的所在。 除了帐篷，我的都干净。
即使在不知不觉中，每个人通常都有自己的算法来帮助进行此选择。 以我的同事和朋友为例，我想这些往往会有很大的不同。 我认识过一些人，这些人是根据一生中必看的一则新闻来决定的，而我也认识了那些寻求最有前途的副牌阵容的人。 哎呀，我敢打赌，有些人的决定基于一支独立乐队（他们是现有的七名粉丝之一），他们明年可能最终会经历突破。
我也有我的，而且从历史上看，它的运行情况还不错，但是今年我想我也可以看看这些数据。
在过去的几年中，我一直在使用LastFM，它已连接到我的Spotify帐户。 这意味着自注册以来我听过的每首音乐都记录在其中。 我想没有人应该比我更多地了解我在听什么。 除此之外，它们还提供了非常好的API。
事不宜迟，让我们获取过去一年来我听最多的艺术家，由于我们只是编写一些脚本，因此我将使用Python。 LastFM的API可在单个请求中方便地提供此功能：
我将保留我的前300名艺术家的笔迹 。 正如Python的EAFP原则所建议的那样，在访问此长json时 ，我还将其包装在try-except语句中。
现在，我可以以编程方式检索我听最多的艺术家了，我应该将这些信息与一些节日节目一起使用。 为了实现这一目标，我首先想到了废弃某个节日的网站，然后想到了阅读节日阵容聚合器的RSS提要，但最终我选择了SongKick。 该服务通过电子邮件警告我即将关注的艺术家的演出。 原来他们也有一个不错的API！
SongKick将城市组织为metro_areas 。 对于这个快速的示例，我手动获取了一些我愿意前往的城市并搜索了其中的事件：
这包括一些Python著名的列表理解魔术，但没有什么牵强的。
现在，我们只是天真地交叉了这些信息。 我开始觉得这在Scala中看起来会更好。
从这里开始，我们有多种选择。 我们可以提出一种更好的计分方法，其中可以考虑入场费，住宿等。此外，我们可以过滤掉已经看过的乐队。 由于我没有去过的过往音乐会的信息（可以通过编程获得），因此我将其保留下来。 结果已经使我确信。
“但是你不知道你平时听什么吗？”
是的，主要是。 而且我的得分也非常吸引那些艺术家。 关键是，由于Spotify著名的“ Discover Weekly”，每周听到的很多音乐都丢失了，而且大多数时候我都没有努力保存我最喜欢的歌曲。
“但是您可能会喜欢但还不了解的乐队呢？”
虽然这可以通过推荐系统来实现（我们只需要更多的数据来对其进行培训），但这不是我的目标。 虽然我愿意查看其他艺术家的表演，但很少选择要参加的音乐节。 这是进入机器学习的一种有趣的情况，但是我并不需要它来获得答案。
人们喜欢预测事物并看到他们的预测得到验证。 我相信这是我们无数次继续聆听相同音乐的原因之一。 这也是当我们在朋友的播放列表中找到我们知道的一种音乐时，我们感到非常高兴的原因之一。 从这个意义上说，我也很高兴听到某些艺术家的现场表演，当演出不符合工作室标准时，我会感到非常失望。
简而言之，听我们所知道的很有趣。
此方法的一些注意事项
尽管这很有趣并且通常可以很好地工作，但是在某些情况下该方法失败了。 这也是已知的，因为我们只是在制作原型。 我们可以将其视为未来的工作：
- 当从两个不同的API交叉信息时，我们会寻找完全匹配的内容。 我们无法确保他们为同一位艺术家使用相同的命名，特别是因为某些艺术家在样式化他们的名字时往往会变得非常喜欢。 有一些基本的变通办法可以轻松实现。
- SongKick的阵容还不完全是最新的。 在达到上面显示的结果之后，我挖掘了阵容，发现宣布了一些更有趣的名称，这些名称尚未在SongKick的活动中注册。 此外，许多夏季节日并没有宣布大多数名称，有些只是一次宣布了所有名称。
- 如前所述，这可能是一些未在此方法中反映的交易突破者。 例如，入场费远高于我们的标准，或者如果您不能在节日的那一周休假几天。
奥托罗
最初，我只是把这种小练习当作拖延，但最终我想分享获得答案的速度和便捷性。 两种API都提供了一个不错的，干净的界面，可以满足我的需求，Python允许我在大约20分钟的时间内将它们合并在一起。 任何对写作和/或代码的反馈表示赞赏！
我希望您喜欢这个小小的旅程，并希望它激发您查找歌曲和艺术家中的数据的动力！
我也真的希望您最喜欢的艺术家不会对您不利，并且您喜欢夏天的节日！ 为一些人群冲浪，罐头食品做饭做准备，最重要的是：已经清理帐篷了！
